NISTIR  5478 


Framework  for 
National  Information 
Infrastructure  Services 


QC 
100 
.U56 
//  5478 
1994 


U.S.  DEPARTMENT  OF  COMMERCE 
Technology  Administration 
National  Institute  of  Standards 
and  Technology 
Computer  Systems  Laboratory 
Gaithersburg,  MD  20899 


July  1994 


NIST 


NISTIR  5478 


Framework  for 
National  Information 
Infrastructure  Services 


U.S.  DEPARTMENT  OF  COMMERCE 
Technology  Administration 
National  Institute  of  Standards 
and  Technology 
Computer  Systems  Laboratory 
Gaithersburg,  MD  20899 


July  1994 


U.S.  DEPARTMENT  OF  COMMERCE 
Ronald  H.  Brown,  Secretary 

TECHNOLOGY  ADMINISTRATION 

Mary  L.  Good,  Under  Secretary  for  Technology 

NATIONAL  INSTITUTE  OF  STANDARDS 
AND  TECHNOLOGY 
Aratl  Prabhakar,  Director 


ACKNOWLEDGMENTS 


This  report  is  the  result  of  the  efforts  of  many  individuals  who  contributed  to  its 
development,  revision,  and  preparation  for  publication.  The  principal  authors  of  the  report 
were:  William  Majurski  and  Wayne  McCoy  of  the  National  Institute  of  Standards  and 
Technology  (NIST),  James  Pottmeyer  of  the  Defense  Information  Systems  Agency 
(DISA),  Wayne  Jansen,  Richard  Schneeman,  David  Cypher  and  Oscar  Farah  of  NIST. 
In  addition,  material  for  the  report  was  contributed  by:  Martin  Gross  of  DISA,  Anthony 
Villasenor  of  the  National  Aeronautics  and  Space  Administration  (NASA),  Roger  Martin 
and  Fritz  Schulz  of  NIST,  David  Jejferson,  Shirley  Hurwitz,  Yelena  Yesha,  and  Brad 
Fordham  of  NIST,  and  Bruce  Lund  also  of  NIST. 

Valuable  constructive  criticism  was  offered  by:  Duane  Adams  of  ARPA,  George  Cotter  of 
the  National  Security  Agency  (NSA),  Howard  Frank  of  ARPA,  Randy  Katz  of  ARPA, 
Paul  Hunter  of  NASA,  Barry  Leiner  of  ARPA,  and  Shukri  Wakid  of  NIST.  Other 
comments  were  also  provided  by  other  reviewers,  including  Michael  Papillo  of  Houston 
Associates  and  David  Brown  of  Sterling  Software.  Rona  Briere  performed  the  final 
editorial  review  and  Fish  Antonishek  was  responsible  for  the  preparation  of  the 
manuscript. 

The  efforts  of  all  of  the  above  individuals  are  gratefully  acknowledged. 


Oscar  Farah 
Technical  Editor 


IS 


fm 


r-  • t, 


>». 


:v 

■ ■ 3 

' ' ■’■  ...  *■  'V  4'.«'. 

■ - . ■ ;.  ..  ,;  ■ . -.-ai  ."M  , • i 


'’’■1 ’■'•«■;.*!• 


<<ii  c4,'i  

piMjt/T  9tii  iiYfdim  U^r.»ftnq  ndT  ^ 

bft£>  ab'tfibfljwii.  \o  5r& 

vwmUhJ^  ^!2ia  iO'-ia^O 
n^ntiU  -j{/.2;AH)  noiJ,li^«aMA 

htoiV\  l>ci»  innih.^  £vw?i\^'f  ^5:U\^.wVi  v''^  |i^ 


» .1 


lo 

^A^A  ,A.1f;S|^;  ■>!it 

Ito  Mvn 

iioiauoH  lo  V«vrt:»vH 

IfcHfi 

^d) 


■*., 


TO)^  si'iS'jl 

— •!•  i an 

Afs 


04 - 'i 


, 6J 


I- 


?|,|1 


Mi 


sM 


i.' 


ikl-a  •f. 


'"i’  % ■ 


T 

*-  ■.■•it 


f ■*";'■  SS^ 


. lo' 


!^t.  ins^is' !' 


" fcr,yv  '^‘ 


■^ 


Ih 


a’ 


>fkn^ 


PREFACE 


This  framework  document  is  one  of  a series  of  reports  which  together  will  provide  a 
comprehensive  overview  of  the  National  Information  Infrastructure  (Nil)  issues  from  the 
different  perspectives  of  the  three-layer  model  defined  by  the  Information  Infrastructure 
Task  Force  (IITF).  The  May  1994  IITF  report  “Putting  the  Information  Infrastructure  to 
Work”  provides  a “top-down”  upper  layer  (applications)  perspective.  A “bottom-up” 
view  of  the  Services  Architecture  from  the  perspective  of  the  lower  (bitways)  layer  is 
presented  here.  A third  report  (scheduled  for  completion  in  late  summer  1994),  “Open 
System  Environment  Architectural  Framework  for  the  Nil,”  will  present  the  third 
perspective,  a services/interfaces-centric  view  of  the  Nil.  Each  of  these  reports  by  itself 
provides  a critical  view  of  the  Nil  services  and  architectural  framework,  but  it  is  only 
when  viewed  from  aU  three  perspectives  that  the  true  complexity  and  scale  of  the  Nil 
challenge  emerge. 
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EXECUTIVE  SUMMARY 


INTRODUCTION 

The  Services  Framework  as  presented  herein  is  intended  to  serve  as  a point  of  departure 
for  discussing  the  definition,  scope,  and  alignment  of  Nil  services.  It  should  stimulate 
discussions  among  industry,  academe,  government,  and  other  elements  of  the  private 
sector.  The  widest  possible  audience  needs  to  consider  implementation  of  services,  issues 
requiring  legal  resolution  or  governmental  policy,  the  scope  and  responsibilities  of  service 
providers,  and  the  refinement  of  Nil  goals  and  objectives  regarding  smooth  interworking 
of  the  information  infrastructure. 

While  representatives  of  Federal  government  agencies  wrote  this  initial  version  of  the 
Services  Framework,  it  does  not  express  definite  government  requirements,  nor  does  it 
dictate  the  development  of  Nil  services  solely  from  a government  perspective,  although  it 
applies  equally  to  the  government  services  sector.  Contributions  and  comments  from  the 
private  as  well  as  other  public  sectors  will  help  refine  the  Services  Framework.  It  is  hoped 
that  this  approach  will  lead  to  ultimate  harmony  among  today’s  diverse  views  of  Nil 
services. 

Industry  will  develop  most  of  the  Nil  through  investments  in  wireless  communications, 
broadcasting  (cable  and  over  the  air),  telecommunications,  and  computer  technologies. 
Industry,  academe,  and  government  need  to  collaborate  in  writing  the  next  version  of  this 
document  to  reflect  consensus  positions.  This  effort  will  iterate  to  develop  the  Services 
Framework  until  a consensus  Nil  Services  Architecture  evolves. 

MODELING  Nil  SERVICES 

Arrangement  of  Nil  Services 

From  a business  perspective,  the  context  for  provision  of  Nil  services  can  be  represented 
as  in  Figure  ES-1. 

The  key  elements  in  the  figure  are  defined  as  follows:  a bitway  is  a network,  or  the 
various  components  required  to  transmit  and  manage  digital  data  across  the  physical 
pathways  of  the  infrastructure;  an  information  appliance  is  a customer-controlled  device 
used  to  access  services,  and  the  service  provider  to  the  customer  (SPC)  is  the  implementor 
of  an  information  appliance  access  point.  The  bitway-bitway  crossover  represents 
interworking  between  bitways;  such  crossovers  will  be  essential  to  seamless  connectivity 
across  the  NIL  Finally,  the  information  service  provider  provides  services,  such  as  a 
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bulletin  board  or  a yellow-pages  service,  that  can  be  viewed  as  being  outside  or  within  the 
Nil  scope. 


Bitway  Provider  X 

Bitway  Providery 

Service  Provider  to 
the  Customer  (SPC) 


o 


Infrastructure  Service  Provider 

Bitway  - bitway  crossover 
Information  Appiiance  (iA) 

Information  Service  Provider 


Figure  ES-1.  Emerging  Relationships  and  Roles  in  the  Nil  Environment 


Several  important  points  emerge  through  this  model: 

• There  is  the  prospect  of  a broad  competitive  bitway  industry  providing  the 
underpinnings  of  the  Nil. 

• The  SPC,  by  controlling  the  means  by  which  services  are  delivered  to  the 
information  appliance,  to  a large  extent  controls  the  evolution  of  the  Nil. 

• The  capabihty  for  creation  of  new  competitive  services  from  both  within  and 
outside  the  basic  infrastructure  is  intrinsic  to  the  scheme. 
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• The  SPC  need  not  be  one  of  the  conventional  carriers.  The  classic  demarcation  of 
network  and  customer  premises  is  blurring,  as  system  integrators  and  outsourcing 
providers  become  local  access  providers  that  provide  services  even  within  the 
customer’s  premises. 

Service  Environment 

Several  existing  service  environments  will  influence  the  development  of  an  Nil  service 
environment.  Primary  among  these  are  Signaling  Service  7 (SS7)  and  the  Internet.  Work 
is  required  to  define  the  transition  from  these  network/distributed  environments  to  an 
architecture  that  encompasses  the  needs  of  the  Nil,  grows  from  existing  commercial 
offerings,  and  supports  distributed  computing  models  that  evolve  with  the  key  enabling 
services  discussed  below.  There  is  also  a need  for  a large  testbed  for  examining  the 
various  competitive  technologies  in  a research  environment.  In  this  connection,  scalability 
of  the  technologies  will  be  a crucial  factor. 

Nil  Services  Model 

Earlier  characterizations  of  the  Nil  have  represented  its  structure  in  three  layers: 
applications,  services,  and  bitways.  Such  a concept  is  a useful  starting  point,  but  is  too 
general  for  characterizing  specific  areas  of  interest,  and  also  tends  to  represent  only  an 
end-user  view.  The  Nil  Services  Model  builds  on  a variation  of  the  three-layer  model — an 
Open  Data  Network  (ODN)  model  with  an  hourglass  shape.  The  constriction  in  the 
hourglass  corresponds  to  a fourth  layer,  the  ODN  Bearer  Service,  which  allows  higher- 
level  services  transparency  to  the  various  network  technologies  below.  The  Nil  Services 
Model,  depicted  in  Figure  ES-2,  advances  the  ODN  view  by  defining  the  next  level  of 
detail  in  interfaces  between  bitways  and  services  and  between  services  and  applications. 

Two  general  classes  of  services  can  be  defined — ^those  associated  with  (or  nearest)  the 
bitways  and  those  associated  with  (or  nearest)  the  applications  layer. 

The  services  associated  with  the  bitways  are  those  services  that  are  essential  to  the 
operation  of  the  NIL  These  are  called  “core  networking  services”  in  this  document.  They 
consist  of  basic  types  of  services,  such  as  transport,  rate  adaption,  and  interworking 
between  like  and  unlike  types  of  information  providers  (e.g.,  between  different  telecom 
information  providers  and  between  telecom  and  computer  information  providers). 

The  services  on  the  applications  side  are  not  defined  as  concretely  because  of  the  variety 
of  applications  envisioned  for  the  NIL  Here,  rather  than  define  very  specific  services,  a set 
of  “key  enabling  services”  or  “enablers”  is  defined.  These  enablers  perform  the  relatively 
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complex  operations,  such  as  collaboration  and  commercial  transactions,  required  to 
develop  many  of  the  applications  envisioned  for  the  Nil. 


Applications 
Key  Enabling  Services 

Collaboration 
Digital  libraries 
Publishing 

Commercial  Transactions 
Control  Transactions 
Monitoring 
Simulation 


Note:  This  is  NOT  a "layered  diagram."  The  pictorial  partitioning  is  abstract  and  has 
no  relation  to  how  the  listed  services  are  implemented  in  relation  to  one  another 


Figure  ES-2.  Nil  Services  Model. 


The  key  enabhng  services  are  complemented  by  an  additional  set  of  “supporting  services” 
that  may  enhance  core  networking  services  or  may  provide  additional  capabilities  that  can 
be  utilized  in  user  applications. 

Intermediaries  may  also  be  provided  with  different  ranges  of  service.  They  may  span  the 
fuU  distance  between  applications  and  bitway s,  or  provide  specialized  services  covering 
portions  of  this  range. 

An  essential  device  not  shown  in  Figure  ES-2  is  the  information  appliance.  Many  kinds  of 
information  appliances  will  exist,  ranging  in  complexity  from  the  set-top  box  to  high- 
power  workstations. 
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Additionally,  in  practice,  a number  of  constraints  arising  from  “environmental  factors,” 
internal  and  external  to  the  data  to  be  transferred,  place  restrictions  on  the  attributes  of  the 
services  that  may  be  provided.  For  example,  a video  signal  requires  a minimum 
bandwidth,  error  rate,  and  information  appliance  capabihties  to  be  usable  for  transfer  and 
viewing;  thus  the  video  transfer  service  to  be  used  must  have  specific  attributes  based  on 
the  type  of  bitway  and  information  apphance  that  are  to  be  used  to  view  the  video.  A 
prehminary  set  of  these  environmental  factors  includes  the  type  of  data  to  be  transferred, 
the  type  of  bitway  available  for  the  data  transfer,  the  type  and  capabihties  of  the 
information  appliance,  the  type  of  storage  available,  and  the  management  practices  of  the 
information  provider.  Attributes  of  the  services  that  are  required  for  a given  set  of  these 
constraints  include  the  content  and  format  of  the  signal  that  must  be  used,  the 
communications  protocol  required,  the  design  of  the  intermediaries  (if  any  are  to  be  used), 
and  the  network  basic  management. 

The  next  two  sections  describe  in  detail  the  above  Nil  Services  components. 

KEY  ENABLING  AND  SUPPORTING  SERVICES 

The  goals  of  the  Nil  include  eliminating  “stovepiping” ^ and  ensuring  that  functions  are 
performed  in  more  efficient  ways  and  make  better  use  of  technological  advances,  i.e.,  not 
carrying  on  business  as  usual.  One  approach  to  achieving  these  goals  is  to  provide  some  small 
number  of  enabling  technological  capabilities  that  will  span  applications  from  entertainment,  to 
business,  to  government,  to  individuals.  The  seven  key  enabling  services  shown  on  Figure  ES- 
2 were  selected  for  this  purpose. 

Initially,  the  enablers  were  identified  based  on  the  requirements  needed  to  fulfill  the 
national  challenges;  they  were  subsequently  augmented  to  ensure  as  wide  a usage  as 
possible  of  the  Nil  applications  and  capture  the  functionality  that  will  have  strong 
commercial  interest.  Although  every  effort  has  been  made  to  ensure  that  the  enablers 
selected  form  a sufficiently  complete  set,  further  review  and  discussions  of  the  hst  with 
industry,  academic  institutions,  and  other  government  agencies  are  planned  during  the 
document  review  workshop. 

The  NH  wiQ  provide  the  above  enabling  functionality  through  the  definition  and  provision  of 
certain  common  services,  which  may  be  utilized  individually  or  in  conjunction  with  other 
services  in  user  applications.  These  services  are  built  upon  the  NH  core  networking  services 


^In  stovepiping,  the  component  functions  of  an  application  are  tailor-made  to  work  with 
that  application  only. 
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discussed  below  and  may  have  intrinsic  value  of  their  own  or  add  value  to  existing 
infrastructure  services.  The  providers  of  these  services  may  bundle  existing  services  in  novel 
ways;  provide  tools,  aids,  or  graphical  user  interfaces  to  enhance  usability;  or  provide  some 
service  essentially  unrelated  to  the  infrastructure  except  in  using  its  services.  Supporting 
service  providers  include  government  agencies,  large  corporations,  nonprofit  organizations, 
small  businesses,  and  individuals  in  homes  who  might  otherwise  be  classified  as  “users.” 

CORE  NETWORKING  AND  OTHER  SERVICES 

Categories  of  Core  Networking  Services 

The  core  networking  services  of  the  Nil  are  essential  for  the  common  use  or  support  of 
any  application.  Agreement  on  and  implementation  of  such  services  among  bitway  and 
service  providers  will  be  essential  if  the  Nil  is  to  fulfill  its  promise.  The  end  use  of  a core 
networking  service  is  optional,  however,  depending  on  the  circumstances  of  an 
application.  Core  networking  services  are  divided  into  two  classes:  (1)  communication 
services  (interworking/rate  adaption,  NH  Interworking  Protocol,  encoding,  and  transport); 
and  (2)  basic  management  services  (identification,  finding,  protection,  and  billing). 

Intermediaries 

An  intermediary  is  a service  that  provides  functions  by  which  to  interconnect,  adapt,  and 
facilitate  services  offered  by  other  parties.  For  example,  it  is  often  desirable  for  services  to 
be  combined  to  allow  construction  of  larger,  more  capable  services.  The  intermediary  can 
bring  together  the  component  services.  In  the  evolution  of  services,  it  may  happen  that  a 
proprietary  or  “uncommon”  service  becomes  widely  available,  but  its  interface  is  not 
compatible  to  all  potential  users.  An  intermediary  can  then  serve  to  provide  the 
appearance  of  a common  interface  to  the  service  without  modifying  either  the  service’s 
interface  or  the  applications  that  seek  to  use  the  service.  Consequently,  intermediaries 
also  ameliorate  some  aspects  of  interoperability  which  might  otherwise  require  an 
unattainable  consensus  to  realize  a formal  standard.  Well-known  forms  of  intermediaries 
are  brokers,  agents,  traders  and  mediators.  A given  intermediary  implementation  can 
serve  concurrently  in  more  than  one  of  these  forms,  or  roles.  As  in  human  society,  it  is 
expected  that  intermediary  functions  and  technology  will  provide  a highly  competitive 
environment  for  entrepreneurs.  An  intermediary  implemented  by  an  automated  process, 
particularly  an  agent,  may  have  “intelligence”  built  into  it;  that  is,  it  follows  guidelines  and 
has  autonomy  to  react  proactively  to  conditions  it  senses  from  its  functional  environment. 
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Service  Attributes  and  Environmental  Factors 


As  noted  above,  it  is  possible  to  identify  environmental  factors  that  dictate  a set  of 
constraints  that  in  turn  can  be  translated  into  a set  of  attributes  to  facilitate  the 
subclassification  of  services.  Table  ES-1  shows  the  environmental  factors  and  the  service 
attributes  they  affect. 

Table  ES-1.  Correlation  of  Environmental  Factors  to  Service  Attributes^ 


^^\^nviron  mental 
Factors 

Service 

Attributes 

Data  Type 

Bitways 
(Bearer  Service 
Types) 

Information 

Appliance 

Data 

Storage 

Information 

Provider 

(SPC) 

Content/Format 

- Image  Encoding 

- Video  Encoding 

- Speech  Encoding 

- Relational  Objects 

Encoding 

X 

X 

X 

X 

Protocol 

(Communications) 

- Peer 

- Multipoint 

X 

X 

X 

X 

Basic  Management 

- Billing 

- Protection 

- Finding 

- Identification 

X 

X 

X 

Distributed 

Control 

- Access 

- Replication 

- Migration 

- Concurrency 

X 

X 

Intermediaries 

- Agents 

- Brokers 

- Traders 

X 

X 

X 

X 

2 , 

An  X indicates  high  correlation  between  the  environmental  factor  and  the  service 

attribute. 
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allow  a smooth  interconnection  mechanism.  The  most  notable  of  these  issues  include  the 
following: 

• The  SS7  protocol  and  its  interoperability  and  deployment  are  essential  to  the 
interworking  between  the  emerging  wireless  industry  and  the  traditional  telecom 
carriers,  recognizing  as  well  the  significance  of  such  a fundamental  transparent 
protocol  to  the  exchange  between  various  telecom  carriers.  In  this  context,  the 
narrowband  Integrated  Services  Digital  Network  (ISDN)  interface  is  essential  as 
weU. 

• The  above  incremental  interface  and  protocol  technology  is  not  sufficient, 
however,  to  satisfy  the  competitive  technology  needs  of  the  computer, 
entertainment,  and  telecom/wireless  industries.  The  ATM  mechanism  as  defined 
by  some  elements  of  the  B-ISDN  technology  is  a cross-industry  enabler  that  is 
recommended  for  a standard  backbone  “glue.”  Interworking  methods  with  regard 
to  ATM  for  both  bearer  and  even  signaling  services  are  essential. 

• As  the  Internet  expands,  so  does  the  number  of  host  addresses;  the  latter  are 
currently  in  short  supply.  This  problem  is  currently  under  study.  Similarly,  the 
telephone  companies  are  themselves  running  out  of  numbering  plan  addresses.  It 
is  logical  that  as  these  two  components  of  the  Nil  begin  to  converge,  then- 
addressing  issues  must  be  explored  together. 

• Different  networking  technologies  use  dissimilar  techniques  for  transmitting  and 
transforming  their  data  streams.  The  timing  of  the  transmissions  (asynchronous 
and  synchronous),  the  encoding  schemes  used  to  modulate  signals,  and  whether  or 
not  rate  adaption  is  used  are  essential  bitway  interworking  methodologies  that 
need  to  be  addressed. 

The  Internet  concept  and  philosophy  will  need  to  be  examined  in  depth  before  large-scale 
bridging  or  scaling  of  that  network  with  other  heterogeneous  infrastructures  is  carried  out. 
The  Internet  brings  to  the  table  a variety  of  issues  that  need  to  be  researched  further 
before  being  applied  to  the  Nil.  AU  the  basic  ideas  that  have  made  the  Internet  successful 
and  usable  will  need  to  be  rethought.  It  is  imperative  that  further  research  and  integration 
impact  studies  be  done  to  assess  these  issues. 

OPEN  ISSUES 

A number  of  issues  identified  during  the  course  of  this  study  remain  to  be  addressed.  The 
issues  cited  here  are  those  the  government  can  help  resolve  through  law,  regulation,  or 
policy.  Other  service-related  issues  are  omitted  from  this  discussion  because  the  authors 
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believe  that  normal,  competitive  market  forces  will  evolve  effective  problem  resolutions. 
This  collection  of  issues  is  a “starter  set,”  to  which  additions  suggested  by  outside 
reviewers  are  particularly  welcome.  The  issues  are  listed  below  in  order  of  importance, 
based  on  the  immediacy  of  the  need  for  resolution  and  the  adverse  consequences  that 
might  result  from  assuming  an  outcome  that  does  not  finally  occur: 

• Universal  Addressing.  We  are  about  to  exhaust  Internet  Protocol  addresses  as 
well  as  10-digit  telephone  numbers.  If  we  do  not  act  soon  on  universal  addressing, 
a rare  opportunity  will  be  lost.  Electronic  commerce  may  be  slow  to  develop 
without  universal  addressing. 

• Anonymous  Activity.  This  is  an  area  where  strong  emotions  figure.  If  pubhc 
outcry  forces  a legislative  mandate  to  reverse  course,  retrofitting  architectural 
features  to  protect  or  prevent  anonymity  could  be  costly. 

• Universal  Security  Policy.  The  longer  the  wait,  the  more  difficult  it  will  be  to 
implement  a universal  security  policy.  By  waiting  too  long,  the  question  is 
resolved  in  favor  of  no  universal  policy. 

• Standards  of  Proof  for  Resolving  Commercial  Disputes.  Electronic  commerce 
for  other  than  trivial  transactions  cannot  achieve  its  potential  until  progress  is  made 
on  this  front,  although  other  areas  are  not  much  impacted. 

• Registration  and  Licensing.  The  formulations  of  particular  approaches  to 
registration  or  licensing  depend  on  how  the  issue  of  security  policy  is  resolved.  It 
is  another  emotional  issue,  but  it  has  less  impact  on  technical  protocols  and  service 
interfaces. 

• Information  appliance  Interfaces.  The  marketplace  may,  if  left  unencumbered 
by  policy,  come  up  with  one  or  a manageable  few  plug-and-socket  conventions, 
but  such  an  outcome  is  not  certain.  The  economic  impact  of  a heterogeneous 
outcome  could  be  substantial,  but  would  be  dispersed  across  a large  population. 
Failing  to  come  to  grips  with  this  issue  results  in  a year-for-year  shp  in  achieving  a 
standard  solution. 

• Security  Labeling.  Interoperability  of  protection  services  will  entail  overly 
complex  intermediary  services  if  there  are  no  common  concepts  for  labeling. 

• Sufficiency  of  Current  Laws  to  Curtail  Undesired  Behavior.  Hostile  action, 
fraud,  negligence,  invasion  of  privacy,  and  other  undesired  behaviors  will  never  be 
totally  eliminated.  Continual  reworking  of  laws  is  needed  in  the  contest  against 
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“bad  guys” — the  inventive  criminal  and  the  negligent.  Electronic  commerce  and 
certain  life-critical  services  may  be  slow  to  develop  if  legal  development  lags. 


xxu 


1.  INTRODUCTION 


1.1  PURPOSE  AND  SCOPE 

This  document  provides  an  initial  description  of  a framework  for  National  Information 
Infrastructure  (Nil)  Services  (hereafter  referred  to  as  the  Services  Framework),  motivated 
by  emerging  information  technologies.  This  framework  is  not  intended  to  be  prescriptive, 
but  merely  to  emphasize  any  perceived  obstructions  to  achieving  the  Nil  goals  and 
objectives.  It  is  presented  at  a high  level  of  abstraction,  relatively  independent  of 
implementation  techniques  and  specific  technologies;  those  details  are  left  to  product  and 
service  providers  for  their  resolution. 

The  original  goal  of  this  document  was  to  define  an  architecture  for  Nil  services.  Instead, 
this  document  represents  a less  ambitious  attempt  to  define  a framework  within  which 
architectures  of  Nil  services  can  be  discussed.  The  Services  Framework  as  presented 
herein  is  intended  to  serve  as  a point  of  departure  for  discussing  the  definition,  scope,  and 
alignment  of  Nil  services.  It  should  stimulate  discussions  among  industry,  academe, 
government,  and  other  elements  of  the  private  sector.  The  widest  possible  audience  needs 
to  consider  implementation  of  services,  issues  requiring  legal  resolution  or  governmental 
policy,  the  scope  and  responsibilities  of  service  providers,  and  the  refinement  of  Nil  goals 
and  objectives  regarding  smooth  interworking  of  the  information  infrastructure. 

While  representatives  of  Federal  government  agencies  wrote  this  initial  version  of  the 
Services  Framework,  it  does  not  express  definite  government  requirements,  nor  does  it 
dictate  the  development  of  Nil  services  solely  from  a government  perspective,  although  it 
applies  equally  to  the  government  services  sector.  Contributions  and  comments  from  the 
private  as  well  as  other  public  sectors  will  help  refine  the  Services  Framework.  It  is  hoped 
that  this  approach  will  lead  to  ultimate  harmony  among  today’s  diverse  views  of  Nil 
services. 

Industry  will  develop  most  of  the  Nil  through  investments  in  wireless  communications, 
broadcasting  (cable  and  over  the  air),  telecommunications,  and  computer  technologies. 


The  mention  of  certain  commercial  products  in  this  document  does  not  imply  government 
endorsement  nor  intent  to  purchase  specific  items.  The  purpose  of  such  reference  is  for 
example  only. 
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Industry,  academe,  and  government  need  to  collaborate  in  writing  the  next  version  of  this 
document  to  reflect  consensus  positions.  This  effort  will  iterate  to  develop  the  Services 
Framework  until  a consensus  Nil  Services  Architecture  evolves. 

Finally,  as  with  the  development  of  any  framework,  many  issues  have  arisen  that  are 
outside  of  the  scope  of  the  present  effort,  but  can  have  significant  impact  on  meeting  the 
objectives  set  forth.  While  many  of  these  issues  concern  policy  matters,  a large  number 
relate  to  technology  matters  as  well.  Rather  than  attempt  to  develop  a comprehensive  hst 
of  such  issues,  this  document  addresses  those  that  were  sahent  in  preparing  the 
framework. 

Moreover,  this  document  does  not  fnUy  address  the  important  issues  of  data  management, 
user  interface  services,  and  “stable”  object  management  technologies.  It  is  expected  that 
these  topics  will  be  expanded  upon  during  subsequent  reviews  by  industry,  academe,  and 
government. 


1.2  BACKGROUND 

A three-layer  concept  is  used  to  initiate  the  discussion  of  the  Nil  in  this  document.  The 
three  layers  are  bitways,"^  services,  and  apphcations.  It  should  be  noted  that  while  this 
layered  concept  is  used  to  structure  the  discussion,  the  boundaries  between  bitways  and 
services  and  between  services  and  applications  are  in  fact  quite  imprecise. 

Nil  services  include  services  associated  with  bitways  and  those  associated  with 
applications.  The  services  associated  with  bitways,  the  bitway-service  interface,  can  be 
more  easily  defined  because  it  is  evident  that  a limited  set  of  core  services  is  required  for 
the  Nil  to  work  at  aU;  this  set  can  then  form  the  basis  for  the  set  of  bitway  interface 
services.  The  problem  is  much  more  complex  on  the  other  side,  the  application-service 
interface.  There,  the  number  and  type  of  applications  are  essentially  unlimited.  Thus, 
rather  than  attempt  to  identify  the  elemental  services  and  associated  application 
programming  interface  (API)  calls  that  would  be  required  to  build  applications,  a number 
of  key  applications- — ^those  on  the  national  challenge  list,  as  well  as  some  others 


^ The  reader  should  note  that  the  terms  “network”  and  “bitway”  are  used  synonymously 
throughout  this  document.  These  and  other  terms  used  in  the  document  are  defined  in 
Appendix  A. 
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considered  important  to  the  private  sector — ^were  used  to  define  a set  of  broad  services 
termed  “key  enabling  services.” 

These  enablers  were  deliberately  kept  at  a high  level  to  ensure  that  their  number  would  be 
reasonable.  In  fact,  they  are  combinations  of  lower-level  services.  Thus  if  these  enablers 
are  viewed  from  the  perspective  of  their  elemental  components,  they  are  highly 
interdependent,  far  from  providing  an  orthogonal  set  to  characterize  the  application  space. 
However,  if  viewed  as  whole  entities,  they  can  be  considered  “quasi-orthogonal”  since  the 
functional  capabilities  of  each  are  distinct:  no  one  enabler  can  be  replaced  functionally  by 
one  or  more  of  the  other  enablers.  The  reader  is  invited  to  question  the  selection  of 
enablers  and  their  completeness  so  the  list  can  be  enhanced  to  reflect  the  consensus  of 
industry,  academe,  and  government. 

From  a practical  point  of  view,  some  forms  of  these  enablers  already  exist;  they  are 
prograrmning  modules  that  are  part  of  currently  used  applications.  As  part  of  the  Nil, 
they  could  be  implemented  as  agents  or  brokers  and  perform  the  enabling  functions 
described  in  this  paper,  or  they  could  be  broken  down  into  lower-level,  more  basic 
functions  and  implemented  as  combinations  of  these  functions. 

An  abstract  model  has  been  used  to  focus  the  discussion  on  impediments  requiring 
immediate  resolution,  with  an  eye  toward  accelerated  integration  of  existing  infrastructure 
elements  to  provide  key  services  in  the  near  term.  Three  critical  points  have  emerged  in 
this  regard: 

• A small  number  of  key  enabling  services,  which  can  support  a wide  spectrum  of 
applications,  can  be  readily  identified  and  must  be  made  available  to  the 
information  appliance  (a  device  through  which  users  access  information  services). 

• A set  of  core  networking  services  must  be  established  as  the  baseline  for  creating  a 
large  market  for  Nil  information  appliances,  value-added  services,  and  other 
related  products. 

• Common  interfaces  to  and  between  bitways  are  a central  and  cohesive  element  of 
provisioning  Nil  services  and  are  needed  to  accelerate  the  rate  at  which  services 
are  introduced  in  the  market.  A preliminary  review  of  cross-industry 
interconnection  provides  some  specific  recommendations  for  interfaces  and 
protocols. 

To  enable  greater  understanding  of  how  these  critical  points  will  affect  the  realization  of 
the  abstract  model  of  Nil  services,  several  examples  of  Nil  applications  are  provided  later 
in  this  document.  These  examples  show  the  dependence  of  different  types  of  applications 
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on  key  enabling  services  and  core  networking  services.  Current  problems  in  establishing 
interfaces  to  and  between  bitways  are  presented  and  discussed.  The  examples  illustrate 
the  need  for  concerted  efforts  to  systematically  identify  areas  where  standards  will  need  to 
be  developed  and  where  greater  understanding  is  needed  of  how  standards  should  be  used. 
The  examples  also  demonstrate  how  standards  can  be  used  to  connect  diverse  bitways  and 
allow  Nil  services  to  be  combined  to  provide  unprecedented  capabihties  for  the  access  to 
and  exchange  of  information. 


1.3  VISION  OF  THE  Nil 

The  vision  of  the  Nil  that  underlies  this  document  enconpasses  services,  capabilities  and 
opportunities  for  applications,  and  the  roles  of  users  and  service  providers.  To  a degree,  this 
vision  builds  on  previous  reports,  such  as  that  of  the  Conputer  Systems  Policy  Project  [1]  and 
other  sources.  In  addition  to  nationwide  services  for  education,  health  care,  law  enforcement, 
public  safety,  and  manufacturing,  this  vision  also  addresses  entertainment,  home  management, 
and  even  basic  interpersonal  communications.  The  NH  must  facilitate  these  services  by 
providing  the  necessary  communication  modes  for  accessing  and  exchanging  information. 

The  architectural  framework  for  the  NH  results  from  identifying  the  functional  requirements 
and  applications  needed  to  access  information  services,  remote  learning,  commercial 
entertainment,  and  other  interactive  processes.  But  the  legacy  of  existing  services — developed 
in  different  industry  segments  according  to  different  technical  standards,  laws,  and  service-level 
agreements — also  constrains  the  framework.  Although  the  Nil  must  incorporate  particular 
existing  technologies,  the  vision  is  a technology-neutral  approach,  one  of  defining  the  Nil  in 
terms  of  capabilities. 

Among  the  capabilities  assumed  in  the  vision  of  the  Nil  are  the  following: 

• Connectivity — The  full  capabilities  of  the  network  reach  almost  every  home,  school, 
library,  business,  and  hospital,  as  well  as  other  institutions. 

• Network  Features — Ultimately,  the  network  that  connects  everyone  will  carry  two- 
way  video  signals  along  with  voice  and  data,  and  allow  any  user  to  connect  to  any 
other  or  many  others.  Initially,  however,  different  forms  (e.g.,  video,  data)  will  be 
carried  by  different  subnetworks  interconnected  with  each  other  to  form  the 
“network.” 

• Openness  and  Flexibility — All  users  can  affordably  send  information  and  specify  the 
kind  of  information  they  want. 
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• Interoperability — A “network  of  networks”  allows  users  of  different  networks  to 
communicate  easily. 

• Accessibility — People  can  use  the  network  cost-effectively  regardless  of  disability, 
functional  limitation,  or  remote  location.  A user  can  find  desired  information  or 
entertainment  easily  through  directories  or  by  starting  an  “intelligent  agent,”  an 
automated  process  that  is  on  the  lookout  for  information  on  services  that  can  meet  the 
person’s  needs. 

• Privacy,  Security,  and  Assured  Service — The  network  has  safeguards  against  illegal 
intrusion  into  people’s  homes  or  papers,  including  virtual  homes  and  “papers”  kept  in 
computer  storage.  The  network  also  protects  intellectual  property  rights  and  prevents 
theft  of  services.  The  network  resists  threats  to  degradation  or  denial  of  service  that 
can  result  fi’om  malicious  attack,  natural  disaster,  accident,  or  procedural  error.  The 
network  is  reliable  enough  to  support  life-critical  services. 

The  Nil  will  evolve  from  existing  “infrastructure  domains,”  including  commercial 
computer  networks,  telephone  networks,  entertainment  networks,  wireless  networks,  and 
selected  components  of  the  Internet.  The  creative  open  environment  fostered  by  the 
Internet  must  be  balanced  by  the  commercial  network  concerns  of  billing,  security, 
scalability,  legal  liability  (e.g.,  copyrights),  and  export  control.  Interworking  is,  therefore, 
a key  enabler  for  the  Nil.  Because  it  consists  of  interworking  “domains,”  the  Nil 
introduces  many  degrees  of  freedom  for  specifying  service  bundling  and  provisioning.  The 
convergence  of  technologies  and  the  changes  in  the  regulatory  environment  add  to  these 
degrees  of  freedom.  Lines  of  demarcation  among  classical  industry  segments  are 
becoming  blurred. 

The  vision  of  the  Nil  behind  this  document  is  one  in  which  private  industry  provides  almost  all 
of  the  infi'astructure.  Issues  involving  development  of  a Government  Information 
Infi’astructure  (GII)  are  being  addressed  by  the  committee  for  Government  Information 
Technology  Services  (GITS).  To  ensure  universal  access,  some  government  subsidies  may  be 
needed.  There  is  an  essential  difference  between  subsidizing  a service  in  general,  which  distorts 
markets  and  tends  to  drive  out  private  investment,  and  subsidizing  deserving  users.  The 
Services  Framework  establishes  no  requirements  for  particular  service  or  user  subsidies. 

This  vision  is  elaborated  in  subsequent  sections  of  this  document  through  a series  of 
representative  explicit  cases  that  can  be  enabled. 
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1.4  ORGANIZATION  OF  THIS  DOCUMENT 


Section  2 presents  an  Nil  Services  Model  that  defines  the  various  components  of  the 
Services  Architecture,  including  the  key  enabhng  services,  core  networking  services, 
supporting  services,  and  intermediaries.  These  components  are  then  discussed  in  Sections 
3 and  4.  A key  underlying  technology  for  implementing  the  enabhng  services  and 
promoting  the  applications  is  that  of  distributed  systems  and  related  object  management 
techniques;  this  highly  competitive  area  is  not  steady  yet  and  is  briefly  discussed  in 
Appendix  B.  Section  5 covers  the  interconnections  among  the  different  industries  that  will 
be  the  primary  actors  in  the  Nil;  such  interconnection  is  deemed  of  primary  importance  to 
the  orderly  development  of  the  NIL  Section  6 presents  examples  of  Nil  applications  and 
discusses  critical  issues  in  the  implementation  of  the  Nil  Services  Model.  Finahy,  Section 
7 identifies  significant  open  issues  that  need  to  be  addressed. 

In  addition,  five  appendices  are  included.  Appendix  A defines  the  acronyms  and  special 
terms  used  in  this  document.  Appendix  B covers  the  application  environment,  while 
Appendix  C addresses  data  and  knowledge  management.  Appendices  D expands  on  the 
interconnection  of  bitways  (Section  5)  and  Appendix  E contains  a discussion  of  the  Open 
System  Environment  (OSE)  and  its  role  in  the  development  of  applications  in  the  Nil 
environment. 
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2.  MODELING  Nil  SERVICES 


While  the  analogy  of  the  Nil  as  an  information  highway  is  a simple  one,  realization  of  the 
Nil  as  a seamless  open  infrastructure,  emerging  from  present-day  products,  services,  and 
technologies,  is  inherently  complex.  A comprehensive  analysis  of  relationships  among 
applications,  services,  users,  providers,  devices,  databases,  and  bitway  technologies  is  a 
necessary  precursor  to  development  of  an  architecture  for  the  NIL  A meaningful  Services 
Framework  must  simplify  comprehension  by  abstracting  away  insignificant  features,  while 
retaining  enough  detail  to  be  clear  and  informative. 

A primary  goal  motivating  the  development  of  this  Services  Framework  is  to  initiate  a 
dialog  with  the  appropriate  industry,  academic,  and  government  representatives  on  how 
applications,  both  government  and  non-government,  can  be  accommodated  directly,  with 
minimal  difficulty,  in  the  NH  environment. 

This  section  begins  with  a discussion  of  the  Nil  environment  and  the  roles  of  the  service 
provider  to  the  customer  (SPC)  and  the  information  appliance  in  providing  the  services 
envisioned  for  the  NIL  Next  is  an  overview  of  the  existing  and  emerging  service 
environments.  This  is  followed  by  a brief  review  of  some  of  the  models  proposed 
elsewhere  for  the  NIL  A detailed  three-layer  concept  based  on  the  Information 
Infrastructure  Task  Force  (IITF)  model  is  then  presented  as  a basis  for  defining  the 
various  services  required  for  the  Nil  and  the  service  components  discussed  in  the  sections 
that  follow. 


2.1  SERVICES  ROLES  AND  RELATIONSHIPS 

This  view  of  the  Nil  as  “seen”  by  the  information  appliance  highhghts  the  emerging 
industry  arrangements  and  relationships,  especially  from  a business  perspective.  The 
services  provided  to  the  highly  competitive  apphance  market  can  be  seen  in  the  context  of 
this  emerging  business  perspective,  the  SPC,  and  the  user  information  appliance. 


2.1.1  Emerging  Business  Perspective 

Figure  2-1  shows  a view  of  the  Nil  depicting  the  roles  involved  in  the  provision  and  use  of 
services.  The  approach  represented  by  the  figure  is  to  view  services  in  terms  of  how  they 
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will  be  provided  to  users,  including  the  following: 

• What  is  necessary,  at  a functional  level,  to  access  and  coordinate  access  to  these 
services. 

• How  the  services  relate  to  applications  and  to  one  another. 

• Where  competition  opportunities  and  difficulties  might  lie. 

• Where  standards,  or  some  forms  of  interoperability,  are  needed. 

• What  mechanisms  can  be  used  to  integrate  service  access  across  the  Nil. 

• Identification  of  some  of  the  important  roles  and  responsibihties  (although  without 
assignment,  since  that  should  be  the  result  of  policy  and  business  decisions  within 
and  between  the  government  and  the  industries  contributing  services  and  products 
for  the  Nn). 

A representation  of  the  Nil  environment  was  developed  in  which  services  accessed 
through  the  Nil  would  hkely  be  realized.  This  representation  takes  into  account  the 
various  means  of  attaching  to  the  Nil  and  the  various  industries  and  entities  that  would  be 
providing  services  in  this  context.  It  is  important  to  note  that  this  view  is  not  from  the 
perspective  of  any  particular  industry  segment  or  implementation,  nor  is  it  a physical 
representation  of  the  Nil  (e.g.,  it  does  not  show  particular  equipment  or  networks). 

The  component  labeled  “Bitway-Bitway  Crossover”  is  intended  to  represent  interworking 
between  Bitway  X and  Bitway  Y.  Such  crossovers  will  be  necessary  if  seamless 
connectivity  is  to  be  realized  across  the  NIL  The  crossovers  will  likely  entail  both 
technical  and  business  interfaces  between  different  bitways.  Although  some  forms  of 
crossover  currently  exist,  these  tend  to  be  very  special  cases  (e.g.,  between  telephone  local 
exchange  carriers  [LECs]  and  interexchange  carriers  [lECs]). 

Crossovers  are  central  to  bitway  integration.^  The  bitway  provider  can  be  an  EEC,  for 
example,  to  which  the  SPC  is  connected.  Likewise,  there  is  no  technical  reason 
preventing  an  LEC  or  lEC,  for  example,  from  in  some  cases  offering  access  directly  to 
information  appliances  and  acting  as  an  SPC,  much  as  the  LECs  do  today.  It  is  possible 
for  a system  integrator,  outsourcing  provider,  wireless  vendor,  value-added  company,  or 


^Technical  aspects  and  issues  of  bitway  integration  are  discussed  in  more  detail  in 
Section  5. 
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cable  TV  company  to  become  an  SPC.  In  addition,  an  information  appliance  may  receive 
information  from  more  than  one  SPC. 


Figure  2-1.  Emerging  Relationships  and  Roles  in  the  Nil  Environment. 


Another  element  of  Figure  2-1  deserves  mentioning.  It  is  designated  “Information  Service 
Provider.”  One  is  shown  attached  to  an  SPC,  and  another  to  a component  of  Bitway  X. 
The  first  case  is  intended  to  represent  an  information  provider  such  as  a bulletin  board 
operating  out  of  an  individual’s  home.  The  second  case  represents,  for  example,  a yeUow- 
pages  service  provided  by  a business  different  from  the  Bitway  X provider.  Thus, 
information  providers  can  be  viewed  as  being  outside  or  within  the  Nil  scope. 
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Several  important  points  emerge  through  this  model: 

• There  is  the  prospect  of  a broad  competitive  bitway  industry  providing  the 
underpinnings  of  the  Nil. 

• The  SPC,  by  controlling  the  means  by  which  services  are  delivered  to  the 
information  appliance,  to  a large  extent  controls  the  evolution  of  the  Nil. 

• The  capabihty  for  creation  of  new  competitive  services  from  both  within  and 
outside  the  basic  infrastructure  is  intrinsic  to  the  scheme. 

• The  SPC  need  not  be  one  of  the  conventional  carriers.  The  classic  demarcation  of 
network  and  customer  premises  is  blurring,  as  system  integrators  and  outsourcing 
providers  become  local  access  providers  that  provide  services  even  within  the 
customer’s  premises. 

Appliance  Nil 

Uncommon  to 


Figure  2-2.  Relationship  Between  Information  Appliances  and  Service  Providers  to 

the  Customer. 


2.1.2  Service  Provider  to  the  Customer 

The  SPC,  an  essential  part  of  current  and  emerging  networks,  plays  an  even  more 
important  role  in  the  NIL  The  SPC  will  manage  the  overall  service  environment  as  seen 
by  its  customers,  and  provide  some  form  of  integration  and  adaptation  of  the  services 
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offered  elsewhere  in  the  NII.^  Here  “customer”  refers  to  users  of  the  information 
appliance(s)7  The  relationship  between  appliances  and  SPC  is  illustrated  in  Figure  2-2. 

The  general  functions  of  the  SPC  are  as  follows: 

• Provision  of  Service  Interface  Components.  The  SPC  will  supply  the  customer, 
directly  or  indirectly,  with  the  necessary  service  interface  components,  both 
hardware  and  software,  that  wUl  enable  the  customer  to  access  Nil  services 
through  local  networks.  The  service  interface  components  may  be  isolated 
devices,  such  as  converter  boxes,  or  components  for  a generic  device,  such  as 
hardware  boards  and  software  for  a personal  computer.  Some  components  will  be 
general-purpose,  and  others  will  be  service-specific.  A present-day  example  comes 
from  service  provision  by  commercial  computer  networks  such  as  Mosaic  and 
World  Wide  Web,  both  of  which  contain  software  components  that  provide  service 
interfaces.  A software  package  for  a personal  computer  with  Windows  (or 
Macintosh  computer)  is  provided  along  with  the  subscription  to  on-line  services. 
This  package  is  used  to  connect  to  the  service,  manage  the  user’s  session,  and 
present  the  service  on  the  information  appliance.  The  network  providers  control 
the  presentation  of  their  services  on  the  appliance. 

• Local  Service  Access.  The  SPCs  will  specify  the  service  interfaces  to  be  used  to 
access  services  on  their  local  network.  This  will  include  the  bitways, 
communications  protocol,  and  content  and  format  specifications  for  service  access. 

• Local  Common  Adaption.  Through  the  local  service  access,  the  SPCs  will  define 
the  service  interfaces  to  be  used  in  accessing  both  local  provider  services  and  more 
global  Nn  services.  The  SPCs  will  provide  for  the  adaptation  of  global  services  to 
local  common  protocols  and  content  and  format  specifications.  This  will  allow 
information  appliances  to  be  of  simpler  construction  since  only  local  common 
protocols  and  content  and  format  specifications  need  be  supported.  It  should  also 
be  possible  to  pass  service  access  directly  to  the  appliance  without  adaption  to 


^In  other  words,  the  user’s  device,  the  information  appliance,  rehes  on  an  SPC  to 
coordinate  elements  (services  and  bitways)  of  the  Nil  and  present  them  in  a usable 
manner. 

^The  information  appliance  here  may  be  an  end-user’s  set-top  box  or  a workstation;  it  may 
also  be  a large  computer  system  on  a business  premise.  That  system  may  be  a user  of  Nil 
services,  a provider  of  Nil  services,  or  both. 
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local  common  formats  to  allow  the  connection  of  more  general/sophisticated 
appliances  that  may  not  comply  with  local  common  interfaces. 


2.1.3  User  Information  Appliance 

Many  kinds  of  user  information  appliances  will  exist,  ranging  in  complexity  from  expanded 
cable  TV  controllers  to  high-powered  workstations.  Two  broad  categories  of  appliances 
are  likely: 

• Low-cost  devices  that  will  fit  into  the  general  category  of  consumer  electronics. 
These  will  be  specifically  tailored  to  accept  services  from  a single  or  small  group  of 
SPCs.  In  an  effort  to  establish  market  share,  the  service  interfaces  for  these 
devices  will  likely  be  proprietary.  This  category  is  called  the  client  apphance  and  is 
very  cost-effective. 

• General-purpose  devices  (descendants  of  today’s  PCs  and  workstations).  These 
devices  will  generally  cost  more  than  those  above,  but  wiU  be  able  to  perform 
many  functions  and  will  be  capable  of  providing  services  to  a broader  range  of 
SPCs.  This  category  of  devices  wiU  perform  the  function  of  server  appliances,  and 
must  be  scalable  with  regard  to  performance,  design,  and  capability. 

The  information  appliance,  or  more  specifically,  classes  of  information  appliances,  wiU 
play  a major  role  in  defining  the  public  view  of  the  NIL  TechnicaUy,  the  interfaces  defined 
for  information  appliances  wUl  be  a controlling  factor  in  the  services  accessible  to  an 
information  apphance  user.  Within  their  relationship  to  the  SPC,  the  information 
apphances’  use  of  service  interface  components  relates  to  many  interfaces  that  exist  in 
computers  today,  such  as  fax  modems,  Ethernet  cards.  Transmission  Control 
Protocol/Intemet  Protocol  (TCP/IP),  and  socket  software.  Many  interface  elements  can 
be  implemented  in  hardware/software  combinations  in  computers,  cable  TV  set-top  boxes, 
and  Integrated  Services  Digital  Network  (ISDN)  video  terminal  adapters. 


2.2  EXISTING  AND  EMERGING  SERVICE  ENVIRONMENTS 

The  mainstay  of  the  current  software  market  supports  a machine-centric  and  local 
operating  system-centric  view  of  computing.  In  terms  of  supplied  functionahty,  support 
for  control  of  networked  environments  is  less  widespread,  and  support  for  the  integration 
of  diverse  networked  environments  is  even  sparser. 
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Currently,  there  are  several  kinds  of  service  environments  from  which  one  can  draw 
examples  that  will  influence  the  development  of  an  Nil  service  environment.  Each  solves 
a different  problem,  aU  of  which  are  apphcable  to  the  challenges  of  the  NIL  Of  these 
environments.  Signaling  System  7 (SS7)  and  the  Internet  are  “standards”-based. 

SS7  is  used  by  telephone  carriers  as  the  basis  for  call  control  and  setup  in  telephone 
networks.  In  the  recent  declaration  of  “Open  SS7,”  local  exchange  and  long  distance 
carriers  have  opened  their  SS7  implementations,  and  have  started  offering  integration 
facihties  to  software  developers  to  encourage  and  facilitate  the  creation  of  a value-added 
service  market  coordinated  via  SS7. 

The  Internet,  an  example  of  a public  network  that  was  originally  created  to  serve  the  needs 
of  researchers  around  the  world,  is  evolving  toward  offering  commercial  services. 
Businesses  are  beginning  to  consider  its  use  in  place  of  private  wide  area  networks. 
Recent  discussions  of  facilities  for  service  bilhng  and  security  indicate  the  Internet’s 
movement  toward  supporting  commercial  needs.  Facihties  for  creating  services  in  the 
Internet  are  available  as  part  of  most  commercial  UNIX  software  environments,  as  weU  as 
other  software  platforms. 

Many  commercial  offerings  provide  local  area  network  technology.  For  example,  Novell 
Netware  has  focused  on  network  technology  for  local  area  networks,  and  is  now 
expanding  with  product  offerings  for  wide  area  networks  and  integration  with  SS7. 

Several  consortia  are  engaged  in  developing  specifications  and  implementations  of 
distributed  systems  technology  (from  which  member  companies  develop  and  offer 
products).  The  Open  Software  Foundation  (OSF)  has  developed  their  Distributed 
Computing  Environment  (DCE)  and  Distributed  Management  Environment  (DME)  to 
solve  basic  problems  in  distributed  computing  and  management.  The  Object  Management 
Group  (OMG)  is  working  on  the  Common  Object  Request  Broker  (CORBA),  which 
details  an  object-based  model  for  distributed  computing;  a broker  architecture  for 
hnking/integrating  object  systems;  and  the  Interface  Definition  Language  (IDL),  which  is 
used  to  describe  the  interfaces  between  communicating  objects.  The  use  of  an  interface 
repository  providing  persistent  storage  of  interface  definitions  is  specified.  These  interface 
definitions  are  intended  to  be  accessible  during  normal  operation  to  enable  dynamic 
binding  of  services  based  on  their  predefined  interfaces. 

Each  of  the  above  kinds  of  service  environments  will  influence  the  development  of  a 
service  environment  for  the  NIL  The  degree  of  uniformity  in  the  underlying  infrastructure 
for  SS7  and  the  Internet  has  led  to  their  broad  use,  which  raises  certain  questions.  For 
example,  as  the  market  for  technologies,  such  as  those  from  OSF  and  OMG,  expands,  will 
it  be  filled  with  competing  implementations  of  a single  technology  or  with  competing  and 
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incompatible  technologies?  The  need  for  compatibihty  in  these  technology  areas  is  critical 
to  the  creation  of  an  infrastructure  for  distributed  computing  on  the  scale  of  the  Internet. 

Work  must  be  done  to  define  how  we  go  from  these  network/distributed  environments  to 
produce  an  architecture  that: 

• Encompasses  the  needs  of  the  NIL 

• Grows  from  existing  commercial  offerings. 

• Supports  distributed  computing  models  that  evolve  with  the  key  enabling  services. 

There  is  also  a need  for  a large  testbed  for  examining  the  various  competitive  technologies 
in  a research  environment.  This  can  occur  in  the  public  networks  as  an  evolution  of  the 
current  Internet  or  in  the  private  networks,  possibly  as  an  extension  of  SS7.  In  either 
case,  scalability  of  the  technologies  will  be  a crucial  factor. 


2.3  Nil  MODELS 

There  have  been  several  basic  characterizations  of  the  NIL  Most  of  these  represent  the 
structure  in  three  layers:  applications,  services,  and  bitways,  as  shown  in  Figure  2-3.  This 
characterization  has  been  adopted  by  the  IITF. 

The  three-layer  concept  effectively  focuses  attention  on  services,  albeit  in  a roundabout 
way.  Characteristics  of  the  applications  and  bitways  layers  can  be  readily  ascertained 
through  review  of  present-day  infrastructure  elements.  The  top  (applications)  layer  is 
represented  by  various  information  apphances,  including  computers,  workstations, 
telephones,  office  equipment,  and  television  sets.  The  bottom  (bitways)  layer  is 
represented  by  existing  networks,  such  as  those  provided  by  the  telecommunications, 
computer,  entertainment/cable,  and  wireless  service  providers.  Unfortunately,  the  services 
layer  is  somewhat  obscure,  largely  because  of  considerations  such  as  the  following: 

• Whether  entities  considered  to  be  in  the  applications  layer  can  offer  services. 

• Whether  bitways  also  offer  services. 

• Whether  the  activities  of  intermediaries  (e.g.,  agents,  brokers,  or  traders) 
constitute  a service. 
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• The  fact  that  distinctions  between  the  terms  “application”  and  “service”  are 
difficult  to  articulate,  and  most  definitions  tend  to  reflect  one  particular  viewpoint 
or  another,  depending  on  the  specific  industries  involved. 

• The  fact  that  distinctions  between  the  terms  “user”  and  “provider”  are  also  difficult 
to  make  since  a provider  of  a service  can  also  be  a user  of  services  from  some 
other  provider  (e.g.,  telephone  LEC). 

• Whether  the  lines  drawn  between  the  layers  of  Figure  2-3  represent  real  interfaces. 


Figure  2-3.  IITF  Three-Layer  Concept. 


While  the  three-layer  concept  is  a good  starting  point  for  identifying  issues  at  a broad 
level,  particularly  with  regard  to  policy,  it  begins  to  be  less  effective  as  implementation 
details  are  analyzed.  The  main  limitation  of  the  concept  is  that  it  is  too  general,  causing 
difficulties  in  characterizing  areas  of  interest. 

Recently,  a variation  on  the  three-layer  model  was  produced  by  the  NRENaissance 
Committee  of  the  National  Research  Council  [2].  This  model  is  an  Open  Data  Network 
(ODN)  model  depicted  as  an  hourglass.  In  this  model,  an  ODN  Bearer  Service,  an 
abstract  bit-level  forwarding  service,  is  introduced  in  the  services  layer  of  the  three-layer 
model  and  defined  as  an  independent  layer  as  well.  Thus  the  model  is  called  a four-layer 
model.  The  constriction  in  the  hourglass  corresponds  to  the  ODN  Bearer  Service.  The 
implication  of  the  constriction  in  the  hourglass  is  the  need  to  allow  higher-level  services 
transparency  to  the  various  network  technologies  below.  The  ODN  Bearer  Service 
constriction  offers  an  anchor  for  services  above,  abstracting  out  some  of  the  details  of  the 
networks  below  without  viewing  network  technologies  as  monolithic. 
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2.4  Nil  SERVICES  MODEL 


The  ODN  model  has  been  adapted  in  this  document,  as  shown  in  Figure  2-4,  to  define  the 
next  level  of  detail  in  interfaces  between  bitways  and  services  and  between  services  and 
applications.  However,  for  purposes  of  clarity,  the  layered  concept  was  abandoned  in 
favor  of  a pictorial  representation  that  conveys  the  interrelationships  among  the  various 
services. 


Applications 


Key  Enabling  Services 

Collaboration 
Digital  Libraries 
Publishing 

Commercial  Transactions 
Control  Transactions 
Monitoring 
Simulation 


Note:  This  is  NOT  a "layered  diagram."  The  pictorial  partitioning  is  abstract  and  has 
no  relation  to  how  the  listed  services  are  implemented  in  relation  to  one  another 


Figure  2-4.  Nil  Services  Model. 


Referring  back  to  Figure  2-3,  two  general  classes  of  services  can  be  defined-— those 
associated  with  (or  nearest)  the  bitways  and  those  associated  with  (or  nearest)  the 
applications  layer.  The  principal  difference  between  these  two  types  of  services  is  their 
complexity. 

The  services  associated  with  the  bitways  are  those  services  that  are  essential  to  the 
operation  of  the  Nil.  These  are  caUed  “core  networking  services”  in  this  document.  They 
consist  of  basic  types  of  services,  such  as  transport,  rate  adaption,  and  interworking 
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between  like  and  unlike  types  of  information  providers  (e.g.,  between  different  telecom 
information  providers  and  between  telecom  and  computer  information  providers).  The 
different  interfaces  provided  to  the  bitways  reflect  the  diversity  in  the  forms  of 
transmission  that  the  Nil  will  support. 

The  services  on  the  applications  side  are  not  defined  as  concretely  because  of  the  variety 
of  applications  envisioned  for  the  Nil.  Here,  rather  than  define  very  specific  services,  a set 
of  “key  enabling  services”  or  “enablers”  is  defined.  These  enablers  perform  the  relatively 
complex  operations,  such  as  collaboration  and  commercial  transactions,  required  to 
develop  many  of  the  applications  envisioned  for  the  Nil. 

The  key  enabling  services  are  complemented  by  an  additional  set  of  “supporting  services.” 
Intermediaries  may  also  be  provided  with  different  ranges  of  service.  They  may  span  the 
fuU  distance  between  applications  and  bitways,  or  provide  specialized  services  covering 
portions  of  this  range. 

Additionally,  in  practice,  a number  of  constraints  arising  from  “environmental  factors,” 
internal  and  external  to  the  data  to  be  transferred,  place  restrictions  on  the  attributes  of  the 
services  that  may  be  provided.  For  example,  a video  signal  requires  a minimum 
bandwidth,  error  rate,  and  information  appliance  capabilities  to  be  usable  for  transfer  and 
viewing;  thus  the  video  transfer  service  to  be  used  must  have  specific  attributes  based  on 
the  type  of  bitway  and  information  appliance  that  are  to  be  used  to  view  the  video.  A 
preliminary  set  of  these  environmental  factors  includes  the  type  of  data  to  be  transferred, 
the  type  of  bitway  available  for  the  data  transfer,  the  type  and  capabilities  of  the 
information  appliance,  the  type  of  storage  available,  and  the  management  practices  of  the 
information  provider.  Attributes  of  the  services  that  are  required  for  a given  set  of  these 
constraints  include  the  content  and  format  of  the  signal  that  must  be  used,  the 
communications  protocol  required,  the  design  of  the  intermediaries  (if  any  are  to  be  used), 
and  the  network  basic  management. 

The  next  two  sections  describe  in  detail  the  above  Nil  Services  components. 
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3.  KEY  ENABLING  AND  SUPPORTING  SERVICES 


The  goals  of  the  Nil  include  eliminating  “stovepiping”^  and  ensuring  that  functions  are 
performed  in  more  efficient  ways  and  make  better  use  of  technological  advances,  i.e.,  not 
carrying  on  business  as  usual.  One  approach  to  achieving  these  goals  is  to  provide  some  small 
number  of  enabling  technological  capabilities  that  will  span  applications  fi-om  entertainment,  to 
business,  to  government,  to  individuals.  A set  of  seven  key  enabling  services,  shown  in  Figure 
3-1 , was  identified  in  this  study  and  is  discussed  below.  This  is  followed  by  a description  of  the 
supporting  services,  also  shown  in  the  figure. 
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Applications 


Key  Enabling  Services 

Collaboraxion 
Digital  Libraries 
Publishing 

Commercial  Transactions 
Control  Transactions 
Monitoring 
Simulation 


Supporting  Servces 


Core  Networking  Services 

Interworking  iMenufication 

Rate  Adaption  Finding 

Nil  IP  ( ODN  Bearer  Service)  Btlbng 

Encoding  and  Transport  Protection 
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Computer  T-i 
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Bitway 

Interfaces 

Interfaces 
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Bitways 


Note:  This  is  NOT  a "layered  diagram."  The  pictorial  partitioning  is  abstract  and  has 
no  relation  to  how  the  listed  sen/ices  are  implemented  in  relation  to  one  another 


Figure  3-1.  The  Key  Enabling  Services. 
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In  stovepiping,  the  component  functions  of  an  application  are  tailor-made  to  work  with 
that  application  only. 
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It  is  expected  that  in  the  Nil,  applications  will  be  based  on  individual,  or  possibly 
combinations  of,  key  enabling  services,  supplemented  with  selected  supporting  services, 
and  value-added  core  services.  Where  necessary,  intermediaries  'will  be  used  to  integrate 
services  in  order  to  achieve  interoperation  at  the  application  level.  (Intermediaries  are 
discussed  in  section  4.2).  Examples  of  the  use  of  enabling  services,  support  services,  and 
intermediaries  are  provided  in  section  6. 


3.1  KEY  ENABLING  SERVICES 

The  key  enabling  services  identified  are  as  follows: 

• Collaboration 

• Digital  libraries 

• Pubhshing 

• Commercial  transactions 

• Control  transactions 

• Monitoring 

• Simulation 

Initially,  the  enablers  were  identified  based  on  the  requirements  needed  to  fulfill  the 
national  challenges;  they  were  subsequently  augmented  to  ensure  as  wide  a usage  as 
possible  of  the  Nil  applications  and  capture  the  functionality  that  will  have  strong 
commercial  interest.  Although  every  effort  has  been  made  to  ensure  that  the  enablers 
selected  form  a sufficiently  complete  set,  further  review  and  discussions  of  the  hst  with 
industry,  academic  institutions,  and  other  government  agencies  are  planned  during  the 
document  review  workshop. 

3.1. 1 Collaboration 

Collaboration  is  the  interaction  among  individuals  or  groups  of  individuals  who  may  be 
remotely  located  with  respect  to  one  another,  for  cooperation  on  some  specific 
application.  Examples  of  collaboration  include  medical  consultations  between  doctors  in 
different  parts  of  the  country,  technical  reviews  between  professionals,  and  electronic 
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meetings.  In  some  cases,  the  collaboration  may  involve  no  more  complexity  than  a 
telephone  call.  In  many  instances,  it  will  involve  the  use  of  bidirectional,  point-to- 
multipoint,  or  multipoint-to-multipoint  interactions  using  voice,  image,  and  video  data, 
with  information  appliances  communicating  with  several  other  appliances  and  multiple 
information  servers  simultaneously.  These  types  of  applications  are  several  orders  of 
magnitude  more  complex  than  today’s  point-to-point  voice  and  data  interactions.  Use  of 
intermediaries,  except  to  establish  the  collaboration  liaisons,  is  expected  to  depend  upon 
the  nature  of  the  collaboration  and  the  collaboration  participants.  The  more  complex 
applications  will  require  high  bandwidth  to  handle  multimedia  information.  Acceptable 
error  rates  will  depend  on  the  application. 

Applications  requiring  collaboration  include  the  following: 

• Telecommuting 

• Virtual  organizations 

• Cooperative  development  and  engineering 

• Telemedicine 

• Medical  consultation 

• Arts,  music  and  literature  authoring 

• Entertainment  creation  and  presentation 

- Interactive  television 

- Games 

- Program  authoring 

• Information  sharing 

- Bulletin  boards 

- Net  news  groups 

• Virtual  factory 

• Virtual  department  store 
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• Virtual  classroom 


• News  gathering 

• Interpersonal  communications 

- Voice 

- Video 

- Fax 

- E-mail 

• Scientific  and  technical  research 

• Government  applications  such  as  law  enforcement  and  environmental  regulations 


3.1.2  Digital  Libraries 

The  digital  libraries  enabler  provides  the  abihty  to  create  information  resources  that  allow 
access  to  electronic  publications.  Digital  libraries  function  much  as  public  libraries  do  in 
allowing  access  to  collections  of  books  and  other  materials.  As  such,  the  applications 
developed  using  the  digital  hbrary  enabler  support  access  to  collections  of  electronic 
books,  periodicals,  and  other  publications.  The  use  of  this  enabler  will  make  the  location 
of  the  hbrary  transparent  to  the  user.  The  information  resource  or  resources  in  which 
these  publications  are  located  may  be  at  a single  site  or  may  be  distributed.  This  enabler  is 
distinguishable  from  the  pubhshing  enabler:  the  digital  hbraries  enabler  is  intended  to 
provide  public  access  to  collection  archival  materials,  while  pubhshing  is  intended  for 
timely  distribution  of  materials  for  commercial  purposes. 

Access  to  publications  in  an  application  developed  using  the  digital  hbraries  enabler  wih  be 
on  a “read-only”  basis,  meaning  that  the  users  cannot  change  the  content  of  any 
information  accessed.  Furthermore,  the  enabler  wih  need  to  support  procedures  for 
authorizing  access  to  and  use  of  copyrighted  material  and  for  providing  fair  compensation 
to  holders  of  intellectual  property  rights.  While  many  of  the  items  in  a digital  hbrary  can 
be  used  freely  by  the  public,  and  are  generaUy  not  intended  for  sale,  fees  may  be  charged 
for  access  to  some  materials. 

The  interactions  between  information  appliances  and  the  application  systems  built  upon 
digital  hbraries  wih  be  somewhat  asymmetric.  Numerous,  smah,  nearly  synchronous 
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messages  embodying  requests  will  emanate  from  the  user’s  information  appliance  to  the 
digital  library.  In  response,  the  library  will  send  asynchronous  messages  containing 
relatively  large  amounts  of  data.  The  information  returned  from  a digital  hbrary 
application  will  probably  require  high  transfer  bandwidth  to  accommodate  the  multimedia 
documents.  Requirements  for  privacy  and  transfer  integrity  will  vary,  depending  on  the 
nature  of  the  information  being  accessed  and  the  privacy  requirements  of  the  users. 
Because  of  the  diversity  of  the  information  in  digital  hbraries,  extensive  use  of 
intermediaries  is  expected.  Response  times  should  be  sufficient  to  support  search  and 
browsing  of  library  materials  without  significant  delays.  Information  stored  in  digital 
libraries  will  include  the  following: 

• Books,  journals,  documents,  and  bibliographies 

• Newspapers  and  various  other  documents  providing  public  information 

• Archival  news 

• Catalogs 

• Science  data 

• Videos 

• General  information  about  such  matters  as: 

- Employment  opportunities  and  availability 

- Health  care 

- Social  services 

- Homeless  shelters 

- Religious  resources 


3.1.3  Publishing 

The  pubhshing  enabler  provides  the  ability  to  create  and  distribute  publications.  This 
includes  creation  and  distribution  of  electronic  books,  periodicals,  music,  film,  and  other 
forms  of  art.  These  electronic  publications  can  be  distributed  to  many  different  types  of 
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destinations,  including  private  homes,  businesses,  and  government  offices.  They  may  also 
be  sent  to  digital  library  systems  where  they  can  be  accessed  and  retrieved  by  users. 

The  pubhshing  enabler  is  intended  for  use  in  “for-profit”  commercial  activity.  Therefore, 
it  must  also  support  mechanisms  for  limiting  or  regulating  the  usage  or  reception  of  certain 
kinds  of  published  material.  For  example,  periodicals  may  be  provided  to  private  homes 
or  digital  hbrary  systems  at  a price.  Music,  films,  literature,  and  other  works  that  are 
subject  to  copyright  could  be  offered  for  sale.  Other  legal  restrictions  may  be  associated 
with  access  to  and  usage  of  such  information.  The  pubhshing  enabler  must  therefore 
provide  facihties  to  ensure  copyright  protection  of  pubhshed  material.  This  enabler  may 
also  support  some  means  of  revenue  collection,  possibly  using  remote  pay-per-use 
facihties. 

As  noted  above,  this  enabler  is  distinguishable  from  the  digital  hbrary  enabler  described  in 
the  previous  section.  In  addition  to  assuming  the  creation  and  organized  distribution  of 
publications  that  can  involve  profit-oriented  commercial  activity,  pubhshing  may  also  be 
associated  with  the  notion  of  timehness,  the  abihty  to  produce  items  such  as  newspapers 
and  magazines  within  a certain  time  period.  Digital  hbraries  focus  on  the  creation  and 
maintenance  of  archival  information  resources  that  contain  many  kinds  of  items  (including 
those  produced  through  electronic  pubhshing).  In  this  respect,  the  pubhshing  enabler  can 
be  looked  upon  as  a “producer”  and  “distributor”  of  electronic  publications,  whhe  the 
digital  hbraries  are  “consumers”  and  “holders”  of  publications. 

Generahy  response  time  wih  not  be  critical  in  electronic  pubhshing.  However,  when  there 
is  a cost  associated  with  the  time  interval  over  which  a user  accesses  an  information 
source,  the  enabler  should  support  reasonable  response  times.  Depending  upon  the 
amount  of  information  to  be  transferred  to  the  user,  bandwidth  requirements  for 
distributing  pubhshed  material  could  be  substantial. 

The  pubhshing  enabler  wih  combine  lower-level  Nil  services  to  support  the  following  at 
the  application  level: 

• Electronic  advertising 

• Publication  and  distribution  of  books,  journals,  literature,  arts,  music,  and  other 
documents 

• Newspaper  subscriptions 

• Entertainment  presentations 
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Pay-per-view 

Movies-on-demand 


- Virtual  bookstores  (created  by  combining  the  capabilities  of  the  digital  hbrary 
enabler  and  the  publishing  enabler,  supplemented  by  remote  pay-per-use 
supporting  services) 


3.1.4  Commercial  Transactions 

The  commercial  transactions  enabler  supports  traditional  commerce  activities,  such  as 
quotations;  placement  of  orders;  and  exchange  of  money  for  goods  and  services,  including 
information  goods  and  services.  These  activities  are  closely  analogous  to  classical 
transaction  processing  and  often  have  critical  response  time  requirements.  Because  of  the 
critical  economic  nature  of  such  transactions,  privacy,  security,  and  assurance  of 
successful  completion  of  the  transactions  are  mandatory.  Digital  signatures  for 
authentication  and  nonrepudiation,  for  example,  are  central  features  of  this  enabler. 
Bandwidth  requirements  should  generally  be  low.  Intermediaries  may  be  involved  if  there 
are  repetitive,  standard  functions  to  be  performed,  such  as  currency  translation  or 
transmission  of  Requests  for  Quotes  (RFQs)  to  appropriate  vendors.  Users  of  this  enabler 
include  the  following: 

• Sales  and  marketing  of  goods  and  services 

• Purchasing  of  goods  and  services 

• Digital  money 

• Banking 

• Stock  market  trading 


3.1.5  Control  Transactions 

This  enabler  supports  the  reservation  of  resources  or  facihties,  or  scheduling  and/or 
coordination  processes  among  a group  of  participants.  The  principal  difference  between 
this  enabler  and  the  previous  one  is  the  differing  time  scales  involved.  Commercial 
transactions  are  generally  complete  within  narrow  time  hmits,  usually  a few  seconds  at 
most.  Control  transactions  can  vary  in  action  time  from  less  than  a second  to  weeks. 
Critical  response-time  aspects  do  occur  here,  but  are  not  typical.  Bandwidth  requirements 
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can  vary  as  well,  depending  upon  the  kinds  of  information  to  be  transferred. 
Commitments  may  not  reach  closure  immediately  because  some  transactions  may  be 
outstanding  for  days  or  weeks  following  their  initiahzation.  Typical  applications  of  this 
enabler  involve  the  following: 

• Resource  management 

• Collaboration  scheduling 

• Logistics 

• Just-in-time  production 

• Inventory  management 

• Integration  of  point-of-sale  and  manufacturing  activities 

• Remote  process  control 

• Travel  and  other  reservations 

• Concurrent  engineering 


3.1.6  Monitoring 

Monitoring  involves  data  transfer  to  and  from  sensors  used  to  gather  measurements 
particular  to  some  purpose  and  presumed  environment.  Generally  such  data  transfer 
provides  status  and/or  statistical  information  for  drawing  inferences  on  behavior, 
analogous  to  telemetry  or  security  monitoring.  Monitoring  consists  of  essentially 
unidirectional  information  flow,  with  each  package  of  data  having  a relatively  small,  fixed 
size.  Often  the  nature  of  the  data  is  such  that  loss  of  a package  is  not  critical,  so  that 
extensive  protection  against  loss  is  unnecessary.  Applications  of  this  enabler  include  the 
following: 

• Home  security 

• Fire  protection 

• Environmental  regulation 

• Home  environment  monitoring 
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Hospital  patient  care 
Providing  home  medical  services 


3.1.7  Remote  Process  Simulation 

Simulation  involves  the  modeling  of  real,  imagined,  or  theoretical  environments  using,  in 
some  cases,  high-power  processing  platforms  and  sophisticated  display  units.  Simulation 
contains  an  assumption  of  distribution  of  computation  platforms  and  display  units. 
Distribution  may  involve  use  of  several  processors  that  compute  individual  steps  of  the 
simulation  in  parallel,  with  intermediate  results  being  sent  to  display  sites.  While 
simulation  has  some  similarity  to  collaboration,  the  nature  of  the  interactions  is  essentially 
different,  with  simulation  involving  relatively  infrequent  exchanges  of  information  during 
distributed  processing.  However,  there  is  a requirement  for  tight  response  times  among 
processors,  so  that  very  high-speed  transport  protocols  are  necessary.  Simulation  may 
require  transfer  of  text,  image,  and  possibly  sound  data,  and  may  also  require  very  high 
effective  transfer  bandwidth  with  low  error  rates. 

• Virtual  reality 

• Entertainment 

- Games 

- Interactive  TV 

- Special  effects 

• Medical  procedures 

• Military  training 

• Engineering  designs 

• Scientific  investigation 

• Manufacturing 

• Environmental  modeling 

• Education 
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3.2  SUPPORTING  SERVICES 


The  functionality  of  the  key  enabhng  services  will,  in  part,  depend  on  making  use  of 
common  supporting  services.  Services  within  the  supporting  category  may  be  integrated 
into  key  enabhng  services  or  used  in  conjunction  with  enabhng  and  core  networking 
services  to  develop  user  applications.  The  providers  of  supporting  services  may  bundle 
existing  services  in  novel  ways;  they  may  enhance  core  services  by  providing  tools,  aids, 
or  graphical  user  interfaces;  they  may  also  provide  services  that  are  specific  to  a particular 
industrial  sector  or  government  activity.  In  addition,  supporting  services  could  provide 
capabihties  that  go  beyond  mere  enhancement  of  core  services,  including  services  that 
could  not  be  provided  by  the  Nil  Interworking  Protocol  (IP).  Supporting  service 
providers  wih  include  corporations,  small  businesses,  government  agencies,  nonprofit 
organizations,  educational  institutions,  and  private  individuals  who  might  otherwise  be 
classified  as  “users.”  Several  preliminary  categories  of  supporting  services  are  offered 
below: 


• Specialized  services  for  support  of  key  enabling  services.  These  services  could 
be  integrated  either  into  key  enabhng  services  or  directly  into  application  systems. 
They  would  provide  important  capabihties  relating  to  the  retrieval,  manipulation, 
and  storage  of  information  (Appendix  C provides  further  discussion  of  information 
management  capabihties  and  their  importance  for  ah  categories  of  Nil  services). 
Supporting  services  of  this  type  would  provide  the  following  noteworthy 
capabihties: 

- Knowledge-based  query  processing — the  abihty  to  accept  queries  that  may 
be  imprecise  or  poorly  defined,  and  to  locate  and  retrieve  information  using 
basic  core  finding  services  augmented  by  knowledge-based  methods  for 
semantic  analysis  of  query  content  and  heuristic  search.  The  use  of  such 
techniques  would  permit  effective  processing  of  very  large  amounts  of 
information  that  would  be  computationally  infeasible  to  process  using 
traditional  database  query  processing  techniques. 

- Knowledge  discovery — ^The  abihty  to  analyze  information  in  large  repositories 
in  order  to  identify  relationships  within  data  and  thereby  produce  new  and 
useful  information.  This  service  may  make  use  of  automatic  indexing,  machine 
learning  methods  (such  as  neural  network  techniques),  and  statistical  analysis 
methods. 
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- Data  translation  and  integration — ^The  ability  to  convert  data  from  one  data 
interchange  format  to  another  and  to  package  it  in  a form  acceptable  to  the 
receiver. 

- Knowledge-based  language  translation — ^The  automated  translation  of  text 
from  one  language  to  another  (e.g.,  Spanish  to  English)  using  artificial 
intelligence  machine  translation  methods.^ 

• Industry-specific  supporting  services.  Individual  industries  would  defme 
supporting  services  for  their  own  specific  uses.  These  services  would  be  based  on 
core  services  and  other  supporting  services.  For  instance,  providers  of  reference 
and  bibliographic  service  for  specific  industries  might  wish  to  customize  inteUigent 
query  processing  services  to  analyze  queries  containing  specific  kinds  of  business 
or  technical  information.  Other  industry-specific  services  may  be  unique.  The 
electronic  commerce  industry  could  develop  services  that  support  Electronic  Data 
Interchange  (EDI). 

• Public  (government  sector)  services.  These  include  services  developed  for  use 
by  government  in  acquiring  and  distributing  information.  Public  services  will 
combine  unique  services  developed  specifically  to  satisfy  government 
requirements,  as  well  as  build  on  core  services,  industry-specific  services,  and 
information  management  services. 

• Competitive  versions  of  core  networking  services.  These  include  enhanced 
versions  of  existing  core  services  or  combinations  of  core  networking  services  that 
offer  additional  functionality  or  performance  over  the  core  set.  For  instance,  core 
networking  services  offer  basic  information  search  functions  (discussed  in 
Section  4. 1.2. 2).  Enhanced  competitive  versions  of  this  service,  such  as  a “yeUow 
pages”  catalog  or  finding  services  that  extend  beyond  a local  area,  might  be  offered 
through  the  SPC  for  a fee.  Other  examples  might  be  enhanced  protection  services 
and  supportive  financial  services. 

• Remote  pay-per-use  services.  These  are  services  that  could  be  integrated  directly 
into  applications  to  allow  the  applications  to  be  offered  as  services  for  a fee.  Using 
the  remote/pay-per-use  facihty,  end  users  could  invoke  the  application  system  and 


^ This  supporting  service  category  and  the  previous  one  may  be  implemented  using 
intermediaries. 
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receive  its  services  on  a restricted  basis.  Payment  could  be  provided  using  digital 
cash. 

• Service  support  mechanisms.  Other  services  may  be  provided  for  definition, 
development,  maintenance,  and  management  of  core  services,  enabling  services, 
and  other  supporting  services. 

To  integrate  services  into  applications  more  effectively,  individual  organizations  will 
create  frameworks  and  profiles.  Frameworks  will  serve  as  reusable  templates  for 
application  systems  within  which  key  enabling  and  supporting  services  can  be  selected, 
configured,  and  integrated  with  application  code.  (See  Appendix  B for  further  discussion 
of  frameworks.)  To  facilitate  integration  of  services  and  other  software  and  hardware 
components,  frameworks  will  utilize  interface  bindings  based  on  common  standards  and 
specifications.  These  bindings  will  also  be  used  by  intermediary  services  to  allow  other 
services  to  interoperate. 


3.3  STANDARDS  FOR  EVTEGRATION  OF  SERVICES 

The  National  Institute  of  Standards  and  Technology  (NIST)  Application  Portability  Profile 
(APP)  [3]  provides  a classification  of  services  offered  strictly  within  a computing 
environment.  The  APP  describes  an  Open  Systems  Environment  (OSE),  which  estabhshes 
an  architectural  framework  within  which  components  from  multiple  vendors,  possibly 
using  dissimilar  technology,  can  interoperate.  This  architectural  framework  identifies  key 
interfaces  and  services  exchanged  at  those  interfaces. 

The  APP/OSE  utilizes  a distributed  system  concept,  which  provides  a context  within 
which  an  organization  can  define  a specific  distributed  system  architecture  tailored  to  its 
needs.  The  service  and  interface  definitions  are  used  as  a template  in  selecting  specific 
standards.  They  are  also  used  to  provide  guidance  to  standards  development  where 
needed  standards  are  not  available. 

The  OSE  concept  used  in  the  APP  has  evolved  over  the  last  decade  through  the 
collaboration  of  industry,  government  agencies,  academe,  and  the  standards  community. 
It  incorporates  lessons  learned  from  acquiring,  building,  and  maintaining  distributed 
information  systems.  A brief  summary  of  the  OSE  concept  is  provided  in  Appendix  E. 

The  Department  of  Defense  (DoD)  has  taken  a similar  approach.  The  DoD  Technical 
Architecture  Framework  for  Information  Management  (TAFTM)  provides  guidance  for  the 
evolution  of  the  Department’s  technical  infrastructure.  It  does  not  provide  a specific 
system  architecture.  Rather,  it  provides  the  services,  standards,  design  concepts. 
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components,  and  configurations  that  can  be  used  to  guide  the  development  of  technical 
architectures  meeting  specific  mission  (i.e.,  application  domain)  requirements.  The 
TAFIM  is  independent  of  mission-specific  applications  and  their  associated  data.  It 
introduces  and  promotes  interoperability,  portability  and  scalability  of  DoD  information 
systems. 
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4.  CORE  NETWORKING  AND  OTHER  SERVICES 


The  core  networking  services  and  intermediaries,  highlighted  in  Figure  4-1,  are  discussed 
in  this  section. 
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Note:  This  is  NOT  a "layered  diagram."  The  pictorial  partitioning  is  abstract  and  has 
no  relation  to  how  the  listed  sen/ices  are  implemented  in  relation  to  one  another 


Figure  4-1.  Core  Networking  and  Other  Services. 


4.1  CATEGORIES  OF  CORE  NETWORKING  SERVICES 

The  core  networking  services  of  the  Nil  are  essential  for  the  common  use  or  support  of 
any  application.  Agreement  on  and  implementation  of  such  services  among  bitway  and 
service  providers  will  be  essential  if  the  Nil  is  to  fulfill  its  promise.  The  end  use  of  a core 
networking  service  is  optional,  however,  depending  on  the  circumstances  of  an 
application. 
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Core  networking  services  are  divided  into  two  classes: 

• Communication  services.  These  are  layered  services.  They  include  the 

following: 

- Interworking/rate  adaption 

- Nil  Interworking  Protocol  (IP) 

- Encoding  and  transport 

• Basic  management  services.  These  services  do  not  fit  into  layers,  but  are 

arranged  functionally.  They  include  the  following: 

- Identification 

- Finding 

- Protection 

- Billing 

4.1.1  Communication  Services 

These  services  provide  communication  between  components  of  applications,  infrastructure 
elements,  key  enabling  services,  etc.  for  request  and  response  exchanges,  and  ensure 
correct  interoperation.  These  services  depend  on  the  use  of  a common  bitway  access 
mechanisms,  and  include  error  detection  and  recovery  features  should  the  probability  of 
undetected  or  uncorrected  errors  be  too  high  on  a particular  bitway.  For  example,  in  data 
communications,  communication  services  include  specification  of  the  packet  size, 
compression  technique,  transfer  rate,  and  error  checking  protocol.  As  discussed  later, 
these  characteristics  are  sensitive  to  the  type  of  bitway  used  and  the  data  type  to  be 
moved.  Thus  it  is  expected  that  several  data  transfer  protocols  will  be  defined  for  the  NIL 
In  addition,  it  is  expected  that  data  may  traverse  multiple  bitways  (e.g.,  cellular  to  wirehne 
networks),  and  that  this  should  be  made  transparent  to  higher-level  services.  This  issue  is 
discussed  further  in  Section  5. 


4. 1.1.1  Interworking/Rate  Adaption 

The  Nil  will  be  formed  from  a combination  of  multiple  bitways  offering  a great  variety  of 
information  transmission  options  spanning  wireline,  wireless,  and  satelhte  transfer 
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technologies.  Core  networking  services  define  access  to  bitway  providers  through  a 
collection  of  individual  industry  interfaces.  Bitway s offer  will  vary  widely  in  terms  of  data 
transfer  rate,  available  quality  of  service,  and  synchronization  capabihties.  End-to-end 
connectivity,  as  viewed  by  an  application,  may  involve  a single  provider  or  a mix  of  many 
providers,  much  the  same  as  in  the  current  Internet  and  telephony  environments. 

The  various  industry  segment  bitway  interfaces  shown  at  the  bottom  of  Figure  4-1  are 
user-to-bitway  protocols  that  span,  at  most,  the  lower  three  layers  of  the  Open  Systems 
Interconnection  (OSI)  reference  model  [3].  The  signal  transmitted  to  and  from  these 
interfaces  to  the  external  bitway  environment  is  typically  a bearer  service  channel  with 
some  form  of  framing  and  multiplexing.  The  interworking/adaption  function  is  a signal 
translation  process  from  one  type  of  interface  to  another. 


4.1.1.2  Nil  IP 

The  constriction  in  the  ODN  hourglass  mentioned  in  Section  2,  the  ODN  Bearer  Service, 
corresponds  to  the  core  networking  services  in  this  model,  a major  component  of  which  is 
the  Nil  IP,  a concept  similar  to  the  ODN  Bearer  Service. 

For  more  than  a decade,  the  discussion  of  layering  in  networks  within  traditional  data 
communications  has  centered  on  the  OSI  reference  model.  Within  that  model,  the 
network  service  is  responsible  for  moving  data  between  end-systems.  A connectionless 
mode  network  service  is  provided  by  the  Connectionless  Network  Protocol  (CLNP), 
which  provides  passage  across  dissimilar  interconnected  networks.  Within  the  Internet,  a 
connectionless-mode  network  service  is  provided  by  the  Internet  Protocol.  The  need  for  a 
network  service  and  a related  protocol  also  exists  in  the  Nil.  The  Nil  IP  offers 
transparency  over  the  topology  of  the  entire  network  and  over  the  transmission  media 
used  in  each  segment  or  subnetwork. 

The  Nil  IP  label  is  both  intuitive  and  problematic.  There  is  broad  understanding  within 
the  data  communications  community  of  the  function  of  the  Internet  Protocol  and  the  way 
the  Internet  relies  on  it  to  enable  the  interconnection  of  networks.  The  same  concepts 
apply  to  the  Nil.  However,  data  communications  is  only  a small  part  of  the  task  defined 
by  the  Nil,  and  neither  CLNP  nor  the  Internet  Protocol  has  the  functionality  to  provide  all 
the  necessary  services.  Still,  the  transparency  issues  are  present  in  the  definition  of  bitway 
coordination  for  the  NIL  This  transparency  imphes  the  following  general  abstract 
services: 

• A uniform  system  of  addressing  that  makes  aU  potential  devices  defined  within  the 
Nil  addressable.  These  devices  include  computers,  other  interactive  (possibly 
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mobile)  communication  and  display  devices,  possibly  passive  display  devices,  and 
monitoring  devices  used  in  home  or  industrial  applications. 

• A routing  function  to  direct  flow  through  the  networks.  Routing  depends  on 
network  topology  and  requirements  for  quality  of  service,  synchronization,  and 
multipoint  capability. 

• Establishment  of  quality-of-service  parameters  that  will  drive  the  possibly  real-time 
choice  of  provider  networks  to  be  employed.  Quality-of-service  issues  such  as 
availability  and  rehability  will  be  of  paramount  importance  because  of  the  diversity 
of  network  types  (e.g.,  from  the  inherent  channel  error  characteristics  of  wireless 
communications). 

• Synchronization  specifications  to  describe  synchronization  requirements  between 
information  flows. 

• Multipoint  capabihty  to  support  communication  between  more  than  two  Nil  IP 
terminations.  This  capability  has  imphcations  for  addressing,  routing,  quality  of 
service,  and  synchronization. 

The  Nil  IP  will  consolidate  bitways  of  a more  diverse  nature  than  those  in  the  Internet  or 
OSI  environments.  Given  the  overwhelming  complexity  of  goals  and  implementation  of 
those  goals  in  the  Nil,  it  will  be  necessary  to  hide  aspects  of  bitway-to-bitway  integration 
beneath  this  single  service  interface. 


4.1. 1.3  Encoding  and  Transport 

Transport  mechanisms,  such  as  rehable  end-to-end  protocols,  will  be  needed  to 
interconnect  services  via  the  available  bitways.  The  infrastructure  wiQ  support  many  types 
of  data  with  appropriate  definitions  of  rehabihty.  The  requirements  vary  significantly  from 
computer  data  to  voice  to  video,  thus  defining  multiple  classes  of  transport  mechanisms 
and  protocols.  Encoding  of  data,  voice,  video,  and  computer  information  for  transport 
involves  many  of  the  same  issues.  Encoding  appropriate  for  each  information  type  is 
needed.  Many  of  these  encoding  schemes  already  exist  or  have  well-established  standards 
or  current  standards  efforts.  However,  much  information  that  is  transported  will  contain 
multiple  data  types,  and  appropriate  transport  mechanisms  and  encodings  remain  as 
research  issues. 
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4.1.2  Basic  Management  Services 


A well-defined  set  of  basic  services  can  contribute  to  the  quick  establishment  of  a large 
market  in  which  value-added  services  are  used  to  differentiate  among  offerings.  As  is 
common  in  such  cases,  the  distinction  between  basic  and  value-added  services  is 
sometimes  blurred.  Nevertheless,  the  concept  helps  focus  attention  on  the  more  critical 
aspects  needing  resolution,  some  of  which  are  discussed  below. 


4. 1.2.1  IdentiHcation 

This  aspect  provides  identifiers  for  objects  and  resources  that  serve  a wide  variety  of 
purposes,  including  protection  (e.g.,  authentication),  fault  control,  resource  management, 
and  locating  and  sharing  of  resources.  In  addition,  the  identities  of  users,  information 
appliances,  and  other  principals  outside  the  Nil  require  binding  with  distinct  Nil 
addresses.  Identification  is  used  to  support  the  addressing  function  in  the  Nil  IP. 

A name  space  is  the  set  of  identifiers  used  to  equate  with  entities.  Name  spaces  may  be 
global  (i.e.,  a one-to-one  mapping  between  names  and  entities),  contextual  (i.e.,  one-to- 
many  or  many-to-one  mapping,  depending  on  context),  or  hierarchical  (i.e.,  a global 
identifier  composed  of  subidentifiers).  The  choice  of  identification  affects  the  degree  of 
management  overhead,  the  perspective  on  resource  and  object  access,  relocation, 
replication,  sharing,  etc.  Identifiers  will  exist  at  multiple  levels  of  the  Nil  architecture. 
The  addressing  portion  of  this  functional  area  is  part  of  the  service  definition  of  the  Nil  IP. 


4.1.2.2  Finding 

As  its  name  imphes,  finding  includes  the  search,  initial  evaluation,  selection,  and  linking  of 
resources,  users,  applications,  services,  etc.,  including  informational  components,  without 
prior  configuration  or  specific  knowledge  by  the  requester.  Finding,  of  course,  requires 
the  identification  service.  In  order  to  perform  the  linking  aspect  of  finding,  it  is  critical 
that  at  the  time  of  discovery  of  the  desired  resource,  there  be  available  information 
providing,  in  a consistent/standard  manner,  an  accurate  description  of  the  resource.  This 
description  should  include,  but  not  be  limited  to,  logical  and  physical  structural 
characteristics  of  the  resource,  interface  requirements,  and  references  to  applicable 
standards  with  which  the  resource  is  compliant.  Finding  will  involve  the  use  of  extensive 
data  and  knowledge  management  capabihties,  such  as  distributed  transaction  processing, 
query  language  processing  support,  and  others.  (See  Appendix  C for  further  discussion). 
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4. 1.2.3  Protection 

Many  networks  today  operate  with  little  or  no  protection  for  transactions,  except  that 
offered  through  the  secrecy  of  the  system  (e.g.,  ownership,  technical  details),  simple 
password  schemes,  and  possibly  the  threat  of  legal  action  against  mahcious  conduct.  If 
the  Nil  is  to  have  commercial  success,  it  wiU  need  to  support  a variety  of  individual  and 
organizational  security  policies  that  address  a diverse  set  of  security  requirements.  This 
suggests  that  a comprehensive  security  pohcy  is  needed  for  the  Nil  to  ensure  that  a safety 
net  of  basic  protection  mechanisms  is  in  place.  WhQe  the  many  security  services  of  the 
Nil  cannot  be  expected  to  meet  more  than  the  basic  requirements,  they  should  provide  the 
foundation  on  which  additional  security  services  can  be  established. 

To  meet  the  basic  needs  of  individuals  and  many  businesses,  several  fundamental  security 
services  are  proposed: 

• Authentication  of  the  parties  (including  identification)  providing  and  using 
services 

• Authentication  of  the  source  of  information  received  on  a bitway 

• Integrity  of  the  information  conveyed  by  the  bitway 

Authentication  of  the  parties  can  help  ensure  that  the  correct  parties  are  in  placed  in 
contact  for  dehvery  of  the  intended  service.  It  does  not  ensure  that  during  dehvery,  the 
information  has  not  in  some  way  been  tampered  with.  Source  authentication  ensures  that 
once  parties  involved  in  a service  have  been  authenticated,  the  information  being  provided 
comes  only  from  those  parties.  Information  integrity  ensures  that  the  information  received 
is  the  same  as  that  provided  at  the  source. 

Universal  identification  and  authentication  are  essential  for  rendering  aU  other  security 
services  uniformly  over  the  Nil.  Therefore,  it  is  desirable  to  institute  a common 
authentication  scheme  from  the  outset,  to  avoid  the  establishment  of  noninteroperable 
enclaves.  Common  does  not  necessarily  imply  that  a centralized  authority  is  in  charge,  or 
that  identical  mechanisms  are  used  Nil- wide.  Current  technology  suggests  that  such  a 
scheme  would  entail  the  use  of  public  key  cryptography  and  an  organization  of 
certification  authorities,  and  would  require  that  each  user  and  service  provider  dependent 
on  security  services  register  with  the  proper  authority. 

Ideally,  the  mechanisms  used  to  provide  the  base  security  services  would  be  identical.  In 
practice,  however,  it  is  expected  that  a variety  of  competing  mechanisms  will  prevail. 
Therefore,  it  is  essential  that  mechanisms  of  comparable  strength  be  used  and,  where 
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necessary,  the  means  to  translate  or  otherwise  employ  the  information  used  by  one 
mechanism  be  provided  to  another. 

Beyond  the  fundamental  services,  other  security  services  are  needed  to  protect 
information,  prevent  fraud  and  abuse,  stop  individuals  with  malicious  intent,  and  ensure 
the  privacy  of  individuals  using  the  NIL  Since  the  fundamental  security  services  are 
limited,  they  must  be  supplemented  with  additional  services  to  meet  these  needs.  Such 
additional  security  services  are  regarded  as  value-added  services,  developed  to  meet  the 
needs  of  a particular  application  area,  and  may  require  the  upgrade  or  replacement  of  an 
information  appliance.  Value-added  security  services  envisioned  for  the  Nil  include 
access  control,  data  confidentiality,  nonrepudiation,  and  availabihty.  Advanced  services, 
including  third-party  notary  services  such  as  time-stamp  services,  are  also  expected.  In 
addition,  security  management  services,  such  as  key  management  and  audit,  must  be 
provided. 

While  the  functionality  provided  by  security  services  is  important,  the  level  of  confidence 
one  can  place  in  those  services  is  also  of  significance.  For  a user,  this  may  be  based  simply 
on  a written  contract  with  the  service  provider,  or  it  may  require  further  evidence  of 
compliance  (i.e.,  assurance)  from  the  service  provider.  Elements  of  assurance  may  be 
provided  through  evaluation  of  the  services  by  an  independent  third  party.  Such  an 
evaluation  would  include  assessing  the  effectiveness  of  the  system’s  mechanisms  against 
the  perceived  operational  threat  and  the  correctness  of  their  implementation  within  the 
system. 


4.1.2.4  Billing 

New  abilities  to  pay  for  services  will  be  needed  to  support  the  NIL  There  will  be  a need 
for  digital  cash  that  is  reliable;  offers  reasonable  protection  against  fraud  and  other  misuse; 
and  can  be  accepted  by  the  user,  vendor,  and  financial  communities.  Such  digital  cash, 
which  would  not  require  authentication  of  a user,  would  be  used  to  pay  for  anonymous 
services  such  as  printing  of  a pubhcly  available  document.  It  must  be  possible  to  store 
digital  cash  on  a personal  device  (such  as  a smart  card),  transfer  it  to  a vendor,  and 
convert  it  into  currency.  At  least  some  basic  Nil  services  must  be  available  on  such  a cash- 
and-carry  basis,  without  an  established  relationship  with  the  banking/fmance  community. 
The  digital  cash  must  be  practical  to  use  to  pay  for  smaU  services,  such  as  printing  a 
document  at  a public  kiosk  or  renting  a movie  for  an  hour,  as  well  as  large  services. 

Digital  cash  also  forms  the  basis  for  more  advanced  electronic  funds  services  that  cannot 
be  used  anonymously.  These  services  involve  a financial  third  party  beyond  the  buyer  and 
seller  already  involved  in  a transaction.  Financial  services  common  in  the  current 
banking/finance  industry  will  hkely  be  extended  to  the  electronic  domain.  Obviously,  new 
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forms  may  appear  that  can  take  advantage  of  the  strengths  of  the  information 
infrastructure.  Electronic  forms  of  credit  services,  debit  services,  checking,  money  orders, 
and  other  financial  instruments  are  possible.  Authentication  and  other  security  issues  are 
paramount  for  protecting  the  user,  the  service  supplier,  and  the  financial  service  supplier. 


4.2  INTERMEDIARIES 

An  intermediary  is  a service  that  provides  functions  by  which  to  interconnect,  adapt,  and 
facilitate  services  offered  by  other  parties.  For  example,  it  is  often  desirable  for  services  to 
be  combined  to  allow  construction  of  larger,  more  capable  services.  The  intermediary  can 
bring  together  the  component  services.  Intermediaries  can  be  used  to  integrate  a 
collection  of  supporting  services  and  value-added  core  services  in  order  to  provide  the 
capability  of  a key  enabhng  service.  Similarly,  intermediaries  could  be  used  in  the 
development  of  an  application  system  to  bind  selected  enabling  supporting  services  using  a 
framework  (see  Appendix  B for  further  discussion). 

In  the  evolution  of  services,  it  may  happen  that  a proprietary  or  “uncommon”  service 
becomes  widely  available,  but  its  interface  is  not  compatible  to  aU  potential  users.  In  this 
instance,  an  intermediary  can  serve  to  provide  the  appearance  of  a common  interface  to 
the  service  without  modifying  either  the  service’s  interface  or  the  applications  that  seek  to 
use  the  service.  Consequently,  intermediaries  also  ameliorate  some  aspects  of 
interoperability  which  might  otherwise  require  an  unattainable  consensus  to  reahze  a 
formal  standard.  An  example  of  the  use  of  intermediaries  to  achieve  interoperability  is 
given  in  Section  6.1. 

Well-known  forms  of  intermediaries  are  brokers,  agents,  traders,  and  mediators  (defined  in 
Appendix  A).  A given  intermediary  implementation  can  serve  concurrently  in  more  than 
one  of  these  forms  or  roles.  As  in  human  society,  it  is  expected  that  intermediary 
functions  and  technology  will  provide  a highly  competitive  environment  for  entrepreneurs. 
An  intermediary  implemented  by  an  automated  process,  particularly  an  agent,  may  have 
“intelligence”  built  into  it;  that  is,  it  follows  guidehnes  and  has  autonomy  to  react 
proactively  to  conditions  it  senses  from  its  functional  environment. 


4.3  SERVICE  ATTRIBUTES  AND  ENVIRONMENTAL  FACTORS 

As  discussed  in  Section  4. 1.1. 2,  the  Nil  IP  is  proposed  to  focus  attention  on  managing  the 
complexity  resulting  from  the  many  types  of  bitways  and  the  ways  they  are  presented  to 
services  that  are  users  of  bitways.  In  that  discussion,  the  Nil  IP  is  described  as  a set  of 
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general  abstract  services  that  would  be  provided  by  the  bitway s.  As  suggested  in 
Section  2,  it  is  possible  to  identify  a set  of  environmental  factors,  based  on  the  path, 
equipments,  and  SPC,  that  dictate  a set  of  constraints  which  in  turn  can  be  translated  into 
a set  of  attributes  to  facilitate  the  subclassification  of  services.  Again,  the  reader  is 
encouraged  to  comment  on  the  adequacy  and  completeness  of  both  the  environmental 
factors  and  the  service  attributes. 


4.3.1  Environmental  Factors 

The  current  set  of  environmental  factors  consists  of: 

• The  type  of  data  to  be  transferred.  Although  all  binary,  the  data  to  be 
transferred  vary  in  many  respects  and  can  be  classified  into  different  types, 
including  text,  binary,  image  and  video,  and  sound,  or  a combination  of  types  as 
would  be  the  case  for  multimedia  data.  File  sizes  can  range  from  a few  hundred 
bytes  for  text  data  to  terabytes  for  complete  color  sound  movies. 

• The  type  of  bitway  available  for  the  data  transfer.  Bitway  capacity  and  noise 
immunity  vary  with  the  physical  type  of  bitway,  i.e.,  whether  it  uses  an  unshielded 
twisted  pair,  a coaxial  cable,  or  airways;  the  type  of  modulation  and  carrier 
frequency;  and  the  number  and  noise  figures  of  repeaters  in  the  path  (if  any). 
Usable  bandwidth  can  range  from  a few  kilobytes  per  second  to  several  megabytes 
per  second. 

• The  type  and  capabilities  of  the  information  appliance.  As  discussed  in 
Section  2,  all  information  appliances  vary  in  their  capabilities. 

• The  type  of  storage  to  be  used.  A wide  range  of  storage  devices  exist,  with 
differing  capacities,  access  speeds,  and  data  transfer  rates.  Capacities  range  from 
hundreds  of  kilobytes  (e.g.,  floppy  disks)  to  multiterabytes  (e.g.,  jukeboxes). 

• The  management  practices  of  the  SPC.  The  SPC  may  use  specialized  billing 
methods,  or  may  have  business  agreements  that  limit  its  capabihties  to  provide 
service. 

Once  the  above  constraints  have  been  defined  for  a given  path,  a decision  can  be  made  on 
whether  a given  signal  can  be  transferred  and  what  attributes  the  transferring  service  must 
have. 
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4.3.2  Service  Attributes 


The  service  attributes  identified  include  the  following: 

• Content  and  format.  This  attribute  covers  encoding  issues  for  text,  graphics, 
images,  video,  voice,  multimedia,  etc.,  as  well  as  coordinated  combinations. 
Information  encoding  is  an  issue  for  both  storage  and  transmission.  Some  forms  of 
encoding  are  contained  in  the  core  networking  services.  Others  are  specific  to 
individual  industries;  for  example,  the  Motion  Picture  Experts  Group  (MPEG)  2 
specification  details  the  content  encoding  for  video,  and  similar  specifications  exist 
in  telephony  for  voice  encoding.  Information  systems  typically  support  detailed 
schema  for  describing  the  structure  of  information  within  a storage  system  or  as 
encoded  for  transmission.  Relational  databases  (Structured  Query  Language 
[SQL]  accessible)  and  objects  are  common  organization  schemes.  Specific 
attributes  are  needed  to  indicate  the  content  area  (e.g.,  image,  video,  audio,  other 
information),  along  with  detailed  taxonomies  for  each  area. 

• Communications  protocol.  This  attribute  includes  basic  transport  protocols, 
protocols  between  services  such  as  mail  agents,  and  custom  protocols  created  by 
interface  definition  languages  used  to  define  distributed  applications.  Protocols  are 
divided  into  two  subgroups:  peer  and  multipoint. 

• Basic  management.  This  attribute  reflects  the  functions  of  identification,  finding, 
protection,  and  billing,  as  discussed  in  Section  4.1.2. 

• Distributed  control.  There  are  many  forms  and  architectures  for  distributed 
control  within  the  research  community.  There  will  likely  be  many  competing  forms 
of  distributed  control  tailored  to  different  services,  applications,  and  industries. 
Typically,  issues  of  replication,  translation,  migration,  trading,  concurrence,  system 
functions,  and  access  are  considered  elements  of  distributed  control.  This  attribute 
will  evolve  to  describe  these  service  issues. 

• Intermediaries.  This  attribute  covers  a set  of  issues  that  pertain  to 
interconnecting,  adapting,  and  facilitating  services  and  interfaces  (including  the 
user  interface),  and  providing  for  the  implementation  of  technical  policies 
established  by  conventions  in  distributed  control.  This  attribute  distinguishes 
specific  architectures  for  intermediaries  and  issues  within  those  architectures. 

Table  4-1  illustrates  which  environmental  factors  affect  the  various  service  attributes.  The 
definitions  of  some  services  will  center  on  a single  attribute;  that  attribute  then  can  be  used 
to  categorize  the  service.  The  definitions  of  other  services  wiQ  cover  a broad  range  of 
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attributes;  the  implication  is,  then,  that  such  a service  is  dependent  upon  multiple  facets  of 
the  environment  and  is  therefore  more  complex  in  its  categorization. 


Table  4-1.  Correlation  of  Environmental  Factors  with  Service  Attributes^® 


^^^nvironmental 

Factors 

Service 

Attributes 

Data  Type 

Bitways 
(Bearer  Service 
Types) 

Information 

Appliance 

Data 

Storage 

Service 
Provider  to 
Customer 
(SPC) 

Content/Format 

- Image  Encoding 

- Video  Encoding 

- Speech  Encoding 

- Relational  Objects 

Encoding 

X 

X 

X 

X 

Protocol 

(Communications) 

- Peer 

- Multipoint 

X 

X 

X 

X 

Basic  Management 

- Billing 

- Protection 

- Finding 

- Identification 

X 

X 

X 

Distributed 

Control 

- Access 

- Replication 

- Migration 

- Concurrency 

X 

X 

Intermediaries 

- Agents 

- Brokers 

- Traders 

X 

X 

X 

X 

Within  the  context  of  service  attributes,  the  most  basic  form  of  a service  is  termed  an 
elemental  service.  A first  effort  at  defining  elemental  services  focuses  on  services  that  fit 


An  X indicates  high  correlation  between  the  environmental  factor  and  the  service 
attribute. 
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into  a single  service  attribute  group.  More  complex  services  will  involve  multiple  service 
attribute  groups. 
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5.  INTERCONNECTION  OF  BITWAYS  IN  THE  Nil 


The  efficient  interconnection  of  the  bitways  of  some  specific  industries  is  viewed  as 
essential  to  the  success  of  the  NIL  To  facilitate  this  interconnection,  the  core  networking 
services  shown  in  Figure  5-1  are  used. 


Applications 


Key  Enabling  Services 

CoUaboiation 
Oigital  Libraries 
Publishing  ■■■■■■■■■■■■■■■■ 

Commercial  Transactions 
Comrot  Transatnons 
htomumng 
Simulation 


Sappwting  Services 


Core  Networking  Services 

Intenvorking  Ident^ication 

Rate  Adaption  Finding 

Nil  IP  ( ODN  Bearer  Service)  Bdluig 

Encoding  and  Transport  Protection 


Entertainment 

Bitway 

Interfaces 

Wireless 

Bitway 

Interfaces 



Telecom 

Bitway 

Interfaces 

Computer 

Bitway 

Interfaces 

‘ A 

^ ' A 

^ ^ 

1 

Bitwav^ 


Note:  This  is  NOT  a "layered  diagram."  The  pictorial  partitioning  is  abstract  and  has 
no  relation  to  how  the  listed  services  are  implemented  in  relation  to  one  another 


Figure  5-1.  Interconnection  of  Bitways. 


Although  successful  bitway  interconnection  strategies  emphasize  primarily  the  need  for 
interworking  and  rate  adaption  services,  other  core  networking  services,  such  as  encoding, 
transport,  and  a specific  bearer  service,  are  also  required. 

Bitways  will  form  the  rudimentary  thoroughfare  needed  to  move  a variety  of  data  types 
rehably,  efficiently,  and  as  expeditiously  as  possible.  Therefore,  interconnection  of 
dissimilar  underlying  networks  will  most  likely  be  the  focal  point  for  accelerating  the 
implementation  of  Nil  services. 
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To  accurately  characterize  the  interfaces  required  to  interconnect  multiple  industry  bitway 
services,  it  is  necessary  to  identify  service  elements  encompassing  specific  bitway 
functionality.  Services  requiring  various  degrees  of  translation,  demodulation,  conversion, 
compression,  and  manipulation  of  data  may  be  required  to  cross-connect  these  functions. 
Within  today’s  analog  and  digital  supply  and  distribution-based  systems,  there  is  a need  to 
minimize  this  process.  However,  it  is  envisioned  that  for  some  time  to  come,  a great  deal 
of  overhead  associated  with  these  interconnection  activities  will  inevitably  be  introduced 
and  require  management.  Integration  and  the  subsequent  distribution  of  services  and 
information  in  different  formats  from  multiple  suppliers  will  also  be  required. 

This  section  reviews  the  four  key  industries  that  must  be  interconnected,  examines  the 
issue  of  cross-industry  interconnection,  describes  emerging  industries  providing  bitway 
access  services  and  related  information  flow,  summarizes  key  interworking  issues,  and 
presents  some  preliminary  recommendations  related  to  bitway  interconnection. 


5.1  INDUSTRIES  TO  BE  INTERCONNECTED 

Interconnection  of  the  industries  selected  in  this  study  is  essential  to  the  success  of  the 
NIL  To  this  end,  available  interface  technology  bridging  several  cross-industry  networks 
must  be  explored.  In  fact,  current  cooperative  alliances  among  some  of  these  industries 
indicate  a trend  toward  interconnection  and  convergence.  This  information  technology 
and  digital  communications  convergence  is  instrumental  to  the  apphcability  of  the  Nil 
services.  The  NR-related  industries  areas  follows: 

• Computer  industry.  Computers  currently  transmit  data  to  individuals,  as  well  as 
to  other  computers,  principally  to  provide  information  for  education,  news,  and 
business  applications.  Normally,  digital  data  is  transmitted;  the  file  size  can  range 
from  relatively  small  files  to  large,  multimegabyte  files.  The  computer  industry 
includes  aU  the  major  subindustry  vendors,  encompassing  mainframes;  PCs; 
workstations;  and  all  protocol-based  peripheral  equipment  produced  solely  to 
connect  and  access  external  services  via  networks,  cable  systems,  and  airwaves. 

• Telecommunications  industry.  Telecommunications  generally  consists  of  two- 
way  communications,  e.g.,  telephone.  The  data  handled  is  generally  analog  and 
relatively  narrowband.  Most  commonly,  many  channels  are  multiplexed  to  exploit 
the  relatively  larger  bandwidth  of  the  bitway s.  The  current  trend  in 
teleconununications  is  toward  digital  communications.  The  telecommunications 
industry  consists  of  all  the  long-haul  carriers,  LECs,  and  other  access  providers; 
public  and  private  data  networks;  and  the  associated  equipment  providers.  These 
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industries  generally  provide  the  backbone,  local  exchange,  and  signaling  networks 
used  to  facilitate  local  and  long  distance  connectivity.  Higher-level  services  in  the 
form  of  applications,  intelhgent  agents,  and  network  transport  services  will  all  use 
these  providers. 

• Entertainment  industry.  At  present,  the  entertainment  industry  uses  primarily 
one-way  communications.  The  data  is  usually  analog  and  relatively  wideband. 
The  transmission  medium  is  also  primarily  analog,  so  that  the  term  “bitway”  is  not 
yet  apphcable  to  the  industry.  Multiplexing  of  a number  of  channels  is  used  in  this 
case  also,  as  the  transmission  medium  used  can  carry  a number  of  channels.  The 
entertainment  industry  includes  a wide  variety  of  fee-for-service  and  over-the-air 
broadcast  entities.  The  term  “entertainment”  is  not  meant  to  exclude  news, 
educational,  and  alerting  services  that  can  be  provided  by  cable  or  over-the-air 
broadcasts.  Because  of  significant  technical  incompatibihties  between  the 
entertainment  bitways  and  other  bitways,  fuU  interworking  may  not  be  achievable 
initially. 

• Wireless  communications  industry.  Wireless  communications  can  be  either 
bidirectional,  as  with  cellular  telephone  and  two-way  radio,  or  unidirectional,  as 
with  broadcasting.  A large  portion  of  the  data  is  currently  analog,  although  the 
trend  here  also  is  toward  digital  data.  The  bandwidth  requirements  range  from  low 
to  relatively  high.  Geographically  dispersed  areas  that  are  otherwise  not  cost- 
effective  locations  for  laying  cable  can  be  served  using  the  current  radio- 
microwave and  future  wireless-based  technology.  Fleets  of  satelhtes  in  various 
orbits  are  to  be  launched  in  the  next  few  years  to  carry  various  kinds  of 
information.  The  global  coverage  of  such  satelhtes  makes  them  contenders  for 
providing  widespread  connectivity. 

Other  possible  categories  include  the  education  industry  and  software  vendors.  In  the  area 
of  education,  televised  courses  have  been  offered  by  universities  and  other  educational 
institutions  for  a number  of  years.  Also  common  now  are  interactive  telecasts  in  which 
students  are  located  in  classrooms  that  are  physically  distant  from  the  teachers.  With  the 
advent  of  the  Nil,  interactive  capabihties  wih  be  extended  to  homes  and  offices, 
significantly  increasing  educational  opportunities.  Section  6.4  provides  an  example  of 
how  the  Nil  could  be  used  to  provide  unprecedented  interactive  educational  opportunities. 
Software  vendors  are  yet  another  industry  category  that  could  be  included.  The  latter  will 
be  impacted  by  a significant  number  of  interoperability  issues  involving  network  software, 
database  systems,  and  other  applications. 
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5.2  CROSS-INDUSTRY  INTERCONNECTION  PROFILE 


Table  5-1.  Skeleton  of  Cross-Industry  Interconnection  Profile  Table 


Industries  -> 

4 

Computer 

Telecom 

Entertainment/ 

Cable 

Wireless 

Computer 

Bitways: 

Content/Format: 

Comm.  Protocol: 

Core  Net.  Serv.: 
Intermediaries: 

Dist.  Ctrl.: 

Telecom 

Entertainment/ 

Cable 

Wireless 

It  is  expected  that  the  industry  segments  hsted  above  will  interconnect  their  networks 
within  the  NIL  Thus,  it  is  required  not  only  that  a computer  (data  communications) 
industry  be  capable  of  communicating  with  other  industries  of  its  own  type,  but  also  that  it 
communicate  with  the  other  three  types  of  Nil-related  industry  (telecommunications, 
entertainment,  and  wireless  communications).  To  illustrate  the  interconnections  between 
the  different  industries,  a cross-industry  interconnection  profile  table,  shown  in  Table  5-1, 
may  be  used.  The  column  and  row  headers  are  the  industries  themselves,  and  at  the 
intersections  of  the  rows  and  columns  are  place  holders  for  the  network  types  and 
services: 

• Bitways 

• Content/format 

• Communications  protocol 

• Core  networking  services 
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• Intermediaries 


• Distributed  control 

A completed  version  of  this  table  showing  currently  available  interfaces  would  highlight 
areas  of  weakness  and  consensus,  and  identify  areas  needing  increased  cooperation  and 
further  research  and  development  efforts. 


5.3  EMERGING  INDUSTRIES 

Several  industries  are  emerging  to  provide  bitway  access  services  and  related  information 
flow.  These  providers  will  need  to  interconnect,  interoperate,  and  eventually  cross  each 
others’  market  boundaries  in  order  to  deliver  their  unique  services  to  willing  subscribers. 
They  will  comprise  a major  portion  of  the  SPCs.  Therefore,  some  form  of  harmonization 
of  bitway  providers  will  very  likely  occur. 

Information  carried  within  the  Nil  wiU  probably  have  to  traverse  multiple  dissimilar 
backbones  and  physical  media.  It  will  go  through  various  conversions  and  transformations 
before  reaching  its  final  destination.  As  time  passes,  convergence  of  the  data  formats  and 
protocols  used  for  these  transformations  to  a smaller  number  of  standard  approaches 
should  take  place.  Until  such  time,  current  technology  based  on  existing  interfaces  and 
methodologies  will  be  used  to  start  the  introduction  of  Nil  services. 

Currently,  the  trend  is  for  the  major  cable  television  (CATV)  companies  to  combine  their 
services  with  those  of  the  telecommunications  carriers.  This  wiU  inevitably  result  in  the 
combined  CATV/telecommunications  infrastructure  becoming  the  keystone  for  an 
integrated  communications,  entertainment,  and  information  services  network.  Many  steps 
to  this  end  have  already  begun  with  recent  announcements  concerning  various  video-on- 
demand  (VOD)  trials  and  ventures  among  the  major  players.  Results  from  these 
integrated  ventures  are  not  likely  to  occur  rapidly.  Immediate  and  widespread  technology 
deployment  in  these  areas  would  be  precluded  by  the  variety  of  diverse  backbone, 
signahng,  and  information  payload  carrying  strategies  currently  used  within  the  various 
industries. 
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5.4  KEY  INTERWORKING  ISSUES 


A number  of  interworking  issues  were  identified  while  researching  the  enabhng  services 
for  the  Nil  national  challenges.  Compilation  of  these  issues  represents  a “ground-up” 
approach  to  defining  the  critical  areas  that  will  affect  bitway  interworking. 

In  many  respects,  the  services  offered  by  the  bitways  will  encapsulate  a normalized  view  of 
the  complete  set  of  bearer  services  provided  by  each  participating  interworking  domain. 
Therefore,  it  is  cmcial  that  bearer  services  in  the  various  “islands”  communicate  with  the 
highest  degree  of  compatibihty,  interoperability,  and  efficiency  possible.  The  generic 
issues  listed  below  require  further  definition,  research  and  development,  and  discussion; 
consensus  must  be  achieved  on  these  issues  to  provide  continuity  to  the  service  definition 
process: 

• Addressing  and  routing.  Unique  names  and  consistent  methods  for  routing 
entities  around  on  the  Nil  are  needed. 

• Transport.  Transport  protocols  are  outdated  and  cannot  offer  the  kinds  of 
services  needed  by  the  NIL  Different  applications  can  tolerate  varying  degrees  of 
QOS  requirements;  if  a specific  protocol  generalized  for  a particular  class  of 
service  is  used,  some  applications  may  suffer  as  a result.  A new  generation  of 
transport  protocols  is  needed. 

• Mobility.  Wireless  computing  will  stress  routing,  addressing,  billing,  reliability, 
and  security  techniques. 

• Access  methods.  The  ability  to  provide  so-called  “last-mile”  access  will  be 
required  for  successful  Nil  usage.  Cost-effective,  efficient,  easy-to-use  equipment 
needs  to  be  designed  for  bidirectional  traffic,  with  a variety  of  information 
appliances  in  mind. 

• Quality  of  Service  (QOS).  Network  procedures  and  services  are  needed  to 
guarantee  that  QOS  requirements  for  an  application  wiU  be  met.  Research  is 
needed  to  understand  how  network  components  and  interfaces  can  be  designed  to 
provide  a wide  range  of  QOS  primitives. 

• Security.  Security  wiU  be  required  at  aU  levels  within  the  NIL  The  magnitude  of 
the  security  issues  may  not  be  weU  known,  especiaUy  for  a distributed,  multilevel 
architecture  such  as  that  of  the  NIL  A comprehensive  security  pohcy  wiU  need  to 
be  developed  that  can  be  applied  to  the  Nil  architecture. 
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Network  management.  Management  of  heterogeneous  networks  and  monitoring 
of  traffic  are  necessary  and  will  require  more  research. 


5.5  PRELIMINARY  RECOMMENDATIONS 

As  the  above  discussion  suggests,  national  and,  more  importantly,  international  priority 
must  be  placed  on  interworking  among  the  globally  defined  public  switched  networks,  the 
Internet,  the  entertainment/cable  networks,  and  the  emerging  wireless  environments, 
especially  personal  communication  service  (PCS)  networks.  Such  interworking  will 
enable  a ubiquitous  and  interactive  digital  capabihty  that  will  span  the  United  States,  with 
an  incremental  growth  toward  higher  bandwidth  and  scalable  core  networking  services. 

A prehminary  analysis  has  been  made  of  the  key  interfaces,  related  protocols,  and 
associated  service  attributes  necessary  to  promote  inherent  cross-industry  competition. 
Essentially,  a snapshot  of  bitway  interconnection  technology  can  be  developed  for  several 
communications  networks  involving  different  information  dehvery  media.  Because  of  the 
various  existing  methods  for  information  distribution,  several  important  concerns  must  be 
addressed  to  allow  a smooth  interconnection  mechanism.  The  most  notable  of  these 
concerns  include  the  following; 

• The  SS7  protocol  and  its  interoperability  and  deployment  are  essential  to  the 
interworking  between  the  emerging  wireless  industry  and  the  traditional  telecom 
carriers,  recognizing  as  well  the  significance  of  such  a fundamental  transparent 
protocol  to  the  exchange  among  various  telecom  carriers.  In  this  connection,  and 
with  regard  to  expanding  access  to  the  Internet  and  promoting  digital  low- 
bandwidth  connectivity  to  small  businesses  and  homes,  the  narrowband  Integrated 
Services  Digital  Network  (ISDN)  interface  is  essential.  It  is  within  this  context 
that  the  evolution  of  the  Plain  Old  Telephone  Service  (POTS)  Universal  Service 
paradigm  can  be  articulated. 

• The  above  incremental  interface  and  protocol  technology  is  not  sufficient, 
however,  to  satisfy  the  competitive  technology  needs  of  the  computer, 
entertainment,  and  telecom/wireless  industries.  The  Asynchronous  Transfer  Mode 
(ATM)  mechanism  as  defined  by  some  elements  of  the  broadband  ISDN  (B-ISDN) 
technology  is  a cross-industry  enabler  that  is  recommended  for  a standard 
backbone  “glue.”  Interworking  methods  with  regard  to  ATM  for  both  bearer  and 
even  signaling  services  are  essential. 
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• As  the  Internet  expands,  so  does  the  number  of  host  addresses;  the  latter  are 
currently  in  short  supply.  This  problem  is  currently  under  study.  Similarly,  the 
telephone  companies  are  themselves  running  out  of  numbering  plan  addresses.  It 
is  logical  that  as  these  two  components  of  the  Nil  begin  to  converge,  their 
addressing  issues  must  be  explored  together. 

• Different  networking  technologies  use  dissimilar  techniques  for  transmitting  and 
transforming  their  data  streams.  The  timing  of  the  transmissions  (asynchronous 
and  synchronous),  the  encoding  schemes  used  to  modulate  signals,  and  whether  or 
not  rate  adaption  is  used  are  essential  bitway  interworking  methodologies  that 
need  to  be  addressed. 

Finally,  the  Internet  concept  and  philosophy  will  need  to  be  examined  in  depth  before 
large-scale  bridging  or  scahng  of  that  network  with  other  heterogeneous  infrastructures  is 
carried  out.  The  Internet  brings  to  the  table  a variety  of  issues  that  need  to  be  researched 
further  before  being  applied  to  the  Nil.  Some  of  these  include  current  uses  of  the  Internet 
Protocol,  Internet’s  lack  of  signahng  ability  and  call  control,  security,  naming  and 
addressing,  QOS  capabilities,  rehabihty,  vulnerabihty,  usage  chargeback,  and  access. 
Currently,  system  administration  and  maintenance  are  at  best  done  using  ad  hoc 
coordination.  AH  the  basic  ideas  that  have  made  the  Internet  successful  and  usable  wiH 
need  to  be  rethought.  It  is  imperative  that  further  research  and  integration  impact  studies 
be  done  to  address  these  issues. 
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6.  EXAMPLES  OF  SERVICES 


This  section  presents  service  examples  taken  from  many  of  the  industries  contributing  to 
the  information  infrastructure.  These  examples  illustrate  some  of  the  technology 
challenges  and  apply  many  of  the  elements  of  the  Nil  Services  Model  (see  Figure  2-4). 
Through  these  examples,  an  attempt  is  made  to  identify  critical  issues  that  must  be 
resolved  to  both  integrate  services  described  in  the  Services  Model  and  interconnect 
dissimilar  bitway  technologies.  The  examples  focus  on  the  use  of  service  attributes  in 
adapting  services  and  bitway  interfaces  and  achieving  the  interoperation  necessary  to  make 
the  Nil  a reality.  The  reader  can  see  (1)  the  role  played  by  enabling,  supporting,  and  core 
services  in  providing  advanced  communications  and  information  capabihties,  and  (2)  the 
role  of  service  attributes  in  integrating  individual  services  and  in  interfacing  information 
appliances  and  bitways.  Issues  involved  in  interfacing  bitways,  such  as  those  illustrated  in 
this  section,  will  need  to  be  resolved  to  create  the  Nil  IP. 


6.1  ELECTRONIC  PROCUREMENT 

A small  set  of  issues  in  electronic  commerce  is  addressed  by  this  example  (see  Figure  6-1), 
involving  the  provisioning  of  services  to  implement  the  process  of  carrying  Requests  for 
Quotations  and  quotations.  This  application  is  based  on  the  use  of  a single  key  enabler, 
commercial  transactions,  supported  by  EDI  services.  In  addition  to  the  basic  core 
communications  services,  value-added  security  services  based  on  core  management 
services  are  used  to  ensure  confidentiality  of  transmission.  The  example  also  illustrates  the 
use  of  intermediaries  for  adapting  service  interfaces.  Service  attributes  are  discussed  in 
relation  to  issues  of  integration  and  evolution  of  services  and  applications. 

Electronic  commerce  is  a business  application  for  the  Nil  that  links  buyers  and  suppliers  of 
goods  through  an  electronic  marketplace  in  which  the  basic  procedures  for  commerce 
(i.e..  Requests  for  Quotations,  quotations,  orders,  and  payment)  take  place  over  the 
electronic  infrastructure.  Within  the  participating  organizations,  this  involves  integration 
of  financial  services,  accounting,  product  offering  and  description  data,  inventory  records, 
and  product  and  vendor  histories.  Several  large  testbed/pilot  projects  already  under  way 
utilize  both  value-added  networks  and  the  Internet.  One  of  these  projects  involves  a 
“procurement  mediator”  that  defines  the  electronic  commerce  environment  in  terms  of  the 
following: 

• Establishing  business  relationships  with  suppliers,  banking,  and  customers 
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Offering  (or  coordinating)  the  integrated  technology  for  suppliers  and  customers  to 
support  the  business  relationships 


Procurement 

Procurement 

Workstation 

Mediator 

^pplication\ 

(Procuremerit 

V^oftwarey^ 

Seivice  Interface 
(User/Riovider  Interface) 

\Databas^ 

{ EDI  ^ 

Content/Format  Encrypted  EDI 

V EDI  ^ 

\Encodingy  / 

Protocol  = email 

Bitway  Interface  = N-ISDN 

\ \Encodingy 

f Encryption  j 

Y Encryption  j 

Figure  6-1.  Electronic  Commerce. 


The  procurement  mediator  maintains  databases  of  the  following: 

• Vendors 

• Products 

• Outstanding  quotations  and  orders 

• Customer  and  vendor  profiles 

• Accounting  information 

The  vendor  and  vendor  product  databases  are  maintained  through  business  agreements 
with  the  vendors.  The  outstanding  quotations  and  orders  database  contains  records  on 
quotations  sent  to  potential  customers  and  orders  placed  by  customers.  These  are  used  to 
track  orders  through  vendor  handhng,  shipping,  and  customer  feedback.  Accounting 
information  for  billing  and  vendor  and  customer  histories  is  necessary,  along  with  hnks  to 
digital  money  services. 

To  obtain  membership  in  this  particular  electronic  commerce  community,  a customer  of 
the  procurement  mediator  will  have  purchased  a software  package  (supplied  by  the 
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procurement  mediator)  for  an  existing  machine  and  a narrowband  ISDN  hne  for  the 
premises,  permitting  interaction  with  the  procurement  mediator. 

The  backbone  of  electronic  commerce  is  the  EDI  standard,  which  provides  for  the 
electronic  formatting  of  business  transactions.  Standardized  EDI  (X.12)  messages  and 
X.12  transactions  sets  offer  combinations  of  requests  and  responses  that  have  been 
established  for  many  common  business  functions. 

The  first  application  function  is  the  capability  to  request  a price  quotation  on  a product. 
The  application  software  issues  the  X.12  transaction  set  RFQ,  which  is  then  encrypted. 
The  procurement  mediator  requires  that  aU  RFQs  and  quotations  be  encrypted  since 
confidentiality  is  required  by  many  vendors  to  protect  their  competitive  price  bids.  The 
encrypted  RFQ  is  transferred  via  e-mail  protocols  to  the  procurement  mediator’s  site. 
This  begins  an  RFQ  business  cycle.  Following  review  by  one  or  more  suppliers,  a 
quotation  is  sent  back  to  the  customer  as  an  X.12  transaction  set  Response  to  RFQ, 
ending  this  first  phase  of  the  business  cycle. 

Confidentiality  is  also  a key  motivator  for  maintaining  control  over  distribution  of 
information.  Referring  to  Figure  6-1,  in  the  absence  of  a general  service  interface  such  as 
the  Nil  IP,  a specific  bitway  interface,  narrowband  ISDN,  was  chosen  for  access  to  a 
64  kilobits  per  second  (Kb/s)  bearer  service.  Since  the  application  uses  data 
communications-style  packetized  data,  an  Ethernet-compatible  bridge  was  chosen  to  layer 
packet  data  on  top  of  the  64  Kb/s  circuit,  creating  a logically  extended  Ethernet.  Packet 
filters  on  both  bridges  (one  at  each  site)  ensure  that  packets  are  exchanged  only  between 
the  customer  site  workstation  and  the  procurement  mediator’s  server.  To  integrate  the 
services  needed  to  support  this  application,  two  key  service  attributes  must  be  specified, 
which  form  the  core  of  the  interaction  between  the  two  distributed  parties: 

• Protocol.  The  time  required  for  a vendor  to  compose  a quotation  in  response  to 
an  RFQ  can  be  lengthy.  The  process  does  not  involve  a “once  and  only  once” 
requirement  typical  of  transaction  processing  environments.  It  was  therefore 
decided  that  e-mail  was  an  adequate  protocol  for  transferring  the  quotation 
information. 

• Content/Format.  EDI  encoding  is  based  on  the  X.12  standard.  One  of  the 
strengths  of  electronic  commerce  as  an  emerging  application  is  the  acceptance  of 
EDI  for  formatting  business  transactions,  along  with  the  effort  to  adopt  a large  set 
of  EDI  transactions  to  support  typical  business  needs. 

Beyond  the  focus  of  these  two  key  service  attributes,  the  required  confidentiality  is 
provided  by  a value-added  security  service  that  supplements  basic  protection  core 
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management  services.  In  this  example,  encryption  was  chosen  as  the  means  to  provide 
confidentiality  of  the  information  transfer  across  the  e-mail  links.  As  will  be  shown  later  in 
this  example,  each  technology  (EDI  encoding  and  e-mail  protocol)  associated  with  a 
service  attribute  can  be  replaced  by  another  technology  choice  (for  example,  a second 
customer  using  a different  software  package  that  offers  a different  set  of  integrated 
services).  Each  of  the  services  can  be  adapted  via  intermediaries  to  conform  to  the  needs 
of  the  procurement  mediator.  These  choices  wiU  also  apply  to  most  of  the  examples  that 
follow.  However,  confidentiahty  in  the  form  of  encryption  must  be  enforced  end-to-end 
to  offer  the  necessary  protection.  Therefore,  aU  participating  parties  must  agree  on  a 
common  form  of  encryption  to  be  used.  This  does  not  mean  that  a single  form  of 
encryption  must  be  used  for  aU  applications  or  by  aU  parties.  Common  imphes  only  that  a 
form  of  encryption  available  to  all  parties  to  this  transaction  must  exist.  If  a common  form 
does  not  exist,  then  encryption  serves  to  partition  the  infrastructure  into  two  or  more 
noninteroperating  pieces  or  environments. 

This  example  has  focused  on  the  use  of  services  that  each  strongly  align  with  a single  key 
enabler.  The  result  has  been  a clean  description  of  the  elements  involved,  making  it  easy 
to  imagine  replacing  any  component  service  with  one  that  covers  the  same  service 
attributes,  but  implements  a different  interface,  protocol,  or  encoding.  For  this  to  be  a 
reality,  mechanisms  for  integration  of  services  and  other  software  components  are 
necessary.  Unfortunately,  the  lack  of  technology  for  “easy”  integration  has  forced  services 
and  protocols  down  a different  path.  The  elemental  services  used  in  this  example  are 
already  being  combined  pair-wise  to  form  new  services  that  offer  greater  integration  (and 
therefore  are  more  usable),  but  possibly  result  in  more  complexity  in  the  overall 
environment.  Examples  of  such  compound  services  are  X.435  (integration  of  X.400 
e-mail  and  EDI  encoding)  and  privacy-enhanced  mail  (integration  of  confidentiahty, 
authentication,  and  e-mail). 

The  anticipated  explosion  of  services  in  the  Nil  raises  a serious  question  of  how 
technology  is  to  be  integrated.  Common  integration  mechanisms  are  needed  as  an 
alternative  to  custom  integration.  This  is  not  intended  to  imply  anything  negative  about 
the  two  compound  services  mentioned  above,  but  to  illustrate  the  larger  issue  of  the 
services  architecture  and  the  need  for  solid  technology  to  support  integration  of 
components  in  the  Nil  as  it  grows.  This  issue  of  complexity  is  imphcit  in  the  many  caUs 
for  an  Nil  services  taxonomy  or  “Dewey  Decimal  System”  for  Nil  services.  There  are 
broad  imphcations  regarding  how  to  ensure  the  usabihty,  scalability,  and  interoperabihty 
needed  to  meet  the  national  challenge  goals. 

A second  application  example  is  a slight  expansion  of  the  first.  It  involves  a second 
customer  who  is  actually  a distributor  and  owns  an  in-house-developed  procurement 
management  system.  This  system  does  not  use  EDI  encoding  for  business  transactions. 


6-4 


but  an  internal  format.  Luckily,  it  does  use  e-mail  as  a protocol  for  delivering  the 
transactions.  This  distributor  has  joined  with  the  procurement  mediator  as  a reseller. 
Interoperation  of  their  systems  is  now  a critical  issue,  although  it  was  never  considered 
before  the  contract  that  brought  them  together  in  this  business  arrangement.  As  part  of 
the  integration  plan,  the  distributor  has  added  an  encryption  service  that  is  compatible  with 
that  of  the  procurement  mediator.  The  EDI/non-EDI  encoding  is  then  the  major  hurdle. 
The  technical  solution  is  to  employ  a translator  (an  intermediary)  to  convert  the  e-mail- 
based  internal  formatting  to  EDI  encoding  on  top  of  e-mail.  Since  the  original  internal 
(distributor)  system  did  not  apply  encryption  before  packaging  the  message  for  e-mail  (the 
encryption  is  to  be  done  after  EDI  encoding  and  before  e-mail  packaging),  the 
intermediary  is  implemented  on  a separate  workstation  at  the  distributor  site  that  accepts 
e-mail  messages  from  the  internal  system,  reformats  them  into  EDI  encoding,  encrypts, 
and  transmits  via  e-mail  to  the  procurement  mediator. 

This  second  application  example  has  focused  on  adapting  a legacy  system  to  newer 
technology  in  an  incremental  manner.  There  is  httle  established  technical/architectural 
guidance  available  to  resolve  such  issues  in  the  evolution  of  technology.  The  complexity 
of  evolution  in  this  example  could  have  been  exacerbated  if  the  in-house  procurement 
system  had  already  been  based  on  a compound  e-mail/confidentiality  service  that  used  a 
different  form  of  encryption.  The  users  already  expect  encryption  to  be  end-to-end. 
However,  because  of  changing  business  needs,  the  definition  of  the  scope  of  the 
organization  (i.e.,  what  is  end-to-end)  has  changed.  How  would  new  interfaces  be 
inserted  without  changing  much  more  of  the  technology  central  to  the  existing  system  or 
drastically  changing  the  overall  quality  of  service  visible  to  the  end  user?  Examining  the 
integration  in  light  of  the  service  attributes  emphasizes  several  long-term  integration  and 
evolution  issues  that  must  be  addressed  if  information  technology  is  to  be  allowed  to 
evolve  gracefully. 


6.2  INTERACTIVE  TV  (GAME) 

This  example  involves  the  use  of  the  simulation  enabler  to  realize  a game  played  through 
interactive  television.  Each  of  the  multiple,  distributed  players  assumes  a character  role  to 
be  played  in  a game  scenario  (e.g.,  a Klingon  in  a Star  Trek  game^^).  A character  has 
various  characteristics  (e.g.,  aggressiveness)  and  a set  of  equipment  (e.g.,  weapons)  that 
the  players  can  use  when  their  character  encounters  other  characters  in  enacting  the 


^^Klingon  and  Star  Trek  are  trademarks  of  Paramount  Pictures. 


6-5 


T 


scenario.  Each  player  has  a remote  unit  with  which  movements  of  the  characters, 
equipment,  etc.  can  be  manipulated.  Players  are  not  necessarily  aware  of  each  other,  and 
players  and  characters  can  enter  or  leave  the  game  at  any  time.  However,  one  of  the 
objects  of  the  game  is  for  characters  to  encounter  one  another  in  the  game  scenario.  Such 
encounters  may  be  hostile  or  friendly,  depending  upon  the  nature  of  the  characters. 

The  site  at  which  the  game  simulation  originates  provides  each  player  with  an  initial  region 
or  view  of  the  scenario  in  which  the  game  is  being  played.  Encounters  occur  when  the 
game  characters  move  into  other  regions  or  views.  Simulation  is  assumed  to  take  place  at 
a single  site  to  avoid  complexities  in  character  coordination.  Players  pay  to  enter  a game 
by  means  of  remote  pay-per-use  supporting  services,  with  actual  payment  transmitted 
using  digital  cash  core  management  services.  Optionally,  competitive  versions  of  basic 
core  communications  services  can  be  provided  to  players  to  enhance  the  game.  An 
example  of  this  is  the  use  of  ISDN  D-Channel  Signahng  to  improve  response  times 
experienced  by  players.  Since  not  all  service  providers  may  provide  this  capabihty,  it  must 
be  offered  to  players  at  extra  cost. 


Figure  6-2.  Interactive  Game. 


The  information  apphance  is  a television  set,  and  includes  a character  control  unit. 
Because  of  synchronization  complexities  and  bandwidth  hmitations,  it  is  assumed  that  this 
game  will  be  played  using  wirehne  bitway  technology.  The  complications  from  using  non- 
wirehne  bitways  are  not  technically  insurmountable,  but  the  added  cost  of  doing  so  can 
bring  into  question  the  economic  viability  of  the  game.  It  is  further  assumed,  again  for 
economic  viabihty  reasons,  that  the  game  wiQ  be  played  using  National  Television 
Standard  Code  (NTSC)  television  rather  than  high-defmition  television  (HDTV)  or  other 
digital  television  units;  NTSC  television  is  not  likely  to  disappear  from  the  scene  until 
digital  television  becomes  as  inexpensive  to  own  as  the  NTSC  units  are  today.  Thus, 
NTSC  is  the  transmission  format  for  the  simulated  scenes.  To  conserve  bandwidth,  the 
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picture  frames  may  be  digitized  and  compressed  for  transmission,  adding  another  attribute 
of  content.  Embedded  in  the  signal  may  be  messages  to  players  indicating  scores, 
equipment  status,  etc.  This  will  require  a different  attribute  for  the  message  format. 
Similarly,  character  control  messages  will  be  sent  from  the  players’  control  units  back  to 
the  program  origination  site  for  integration  into  the  game  (see  Figure  6-2). 

The  program  originator  could  be  remote  from  all  players,  e.g.,  a nationwide  game,  or  it 
could  be  provided  locally  through,  say,  a local  CATV  company  or  telephone  company.  In 
either  case,  the  SPC  will  be  responsible  for  signal  conversion  to  the  information  appliances 
to  the  extent  that  the  information  appliances  themselves  are  incapable  of  such  conversion. 
The  character  control  units  will  represent  significant  areas  of  competition  for  game 
manufacturers  such  as  Sega  and  Nintendo.  Commonality  of  interfaces  and  formats  will 
probably  not  be  in  their  interest,  and  only  market  pressure  from  game  players  will  have  any 
influence  in  this  regard. 


6.3  VIDEOCONFERENCING 

This  example  of  collaboration  involves  a point-to-point  videoconferencing  system,  capable 
of  both  video  and  data  interaction,  using  ISDN  as  the  principal  transport  mechanism  (see 
Figure  6-3).  The  example  highlights  issues  involved  in  interfacing  information  appliances 
and  bitways  so  that  the  core  Nil  transport  service  can  be  provided.  On  the  left  of  the 
figure  is  the  information  appliance,  in  this  case  a desktop  computer.  The  principal  service 
interface  component  is  an  ISDN  video  terminal  adapter  that  contains  the  following: 

• An  audio  coder/decoder  (codec) 

• A video  codec 

• A data  interface 

• A multiplexer/demultiplexer 

• ISDN  interface  (Basic  Rate  Interface  [BRI]) 
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Figure  6-3.  Point-to-Point  Video  Conferencing. 


The  multiplexer/demultiplexer  takes  (two  or  more  of)  the  outputs  from  the  data  interface 
and  the  video  and  audio  codecs  and  creates  a single  bit  stream.  The  bitway  connecting  the 
ISDN  interface  to  the  SPC  is  the  ISDN  BRI  in  the  local  subscriber  loop  to  a central  office 
ISDN  switch  of  a telephone  LEG.  Assuming  that  the  video  call  is  leaving  the  local  access 
transport  area  (LATA)  administered  by  this  LEC,  the  video  call  is  carried  by  an  lEC  via 
the  long-distance  network  to  reach  a LATA  and  a central  office  of  the  (usually  different) 
LEC  on  the  other  end  of  the  call,  and  is  then  transmitted  to  the  customer  premises  at  the 
other  end,  where  video  equipment  similar  to  that  above  exists. 

Each  of  the  ISDN  video  terminal  adapter  components  cited  above  has  a particular  format, 
and  in  some  cases  a protocol,  associated  with  it.  There  must  be  compatibility  among  these 
formats  and  protocols  for  the  call  to  be  completed  and  used.  The  International 
Telecommunications  Union  (ITU,  formerly  CCITT)  has  defined  standards  for  each  of 
these  in  Recommendation  H.320: 

• Audio  codec:  G.711,  G.722,  or  G.728 

• Video  codec:  H.261 

• Data  interface:  H.221 

• Mux/demux:  H.221 

• ISDN  interface:  1.400  (series) 

Additionally,  the  video  itself  has  two  formats.  Common  Intermediate  Format  (CIF)  and 
Quarter  CIF,  which  are  selected  on  a bandwidth  availability  and  quality  basis. 
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The  H.261  video  codec  specifications  provide  a format  for  video  compression,  using  a 
discrete  cosine  transform  (DCT)  procedure.  However,  a protocol  associated  with  the 
specification  permits  negotiating  to  another  compression  procedure  if  desired.  This  would 
permit  using  a proprietary  compression  technique,  most  of  which  are  clearly  superior  to 
the  H.261  DCT  procedure.  How  this  negotiation  takes  place  during  an  ISDN  call 
establishment  is  not  specified.  There  is  also  no  specification  as  to  how  the  two  64  Kb/s 
ISDN  B-channels  are  to  be  used:  whether  to  reserve  one  channel  and  use  the  other  to 
carry  the  multiplexed  data,  video,  and  voice;  to  carry  voice  on  one  channel,  and  data  and 
video  multiplexed  on  the  other;  or  to  carry  totally  multiplexed  information  on  both 
channels  to  obtain  the  higher  128  kb/s  bandwidth.  AU  of  these  choices  are  made  by  the 
manufacturer  of  the  ISDN  video  terminal  board.  Thus,  even  with  standards  in  use, 
interoperability  is  dictated  by  the  particular  business  choices  made  by  manufacturers  for 
their  implementations.  Additionally,  it  must  be  noted  that  although  these  are  standards  for 
videoconferencing  equipment,  vendors  are  generally  under  no  obligation  to  adopt  them. 
They  do  so  only  as  business  choices,  and  usually  in  conjunction  with  their  own  proprietary 
approaches. 

Data  and  display  interactivity  between  end-users  is  carried  out  by  protocols  implemented 
in  computer  software  in  the  users’  desktop  systems.  Even  here,  some  compatibility  is 
dependent  on  the  vendors’  commercial  choices  and  the  users’  purchase  choices. 

Although  the  ISDN  standards  and  implementation  agreements  provide  for  a great  deal  of 
interface  compatibility  between  the  central  office  switch  and  the  user  equipment,  a 
particular  carrier  may  elect  not  to  implement  certain  aspects  of  the  service,  or  may  restrict 
the  capability,  for  commercial  reasons.  For  example,  if  one  EEC  elects  to  implement  a 
video  dial  tone  and  the  other  EEC  does  not,  call  establishment  may  be  impaired. 

The  inter-EATA  bitway  for  ISDN  information  uses  SS7  protocols  and  clear  channel 
64  kb/s  transport,  for  each  B-channel  used,  from  the  EEC  central  offices  to  the  EEC’s 
service  control  points  (SCPs)  and  between  SCPs.  The  content  of  the  information  carried 
is  transparent  to  the  EEC’s  systems.  (At  present  there  are  a few  incompatibilities  in  these 
capabihties,  due  to  commercial  choices  in  switch  vendor  selection  and  to  technical  choices 
in  implementing  services  from  the  standards.) 

Finally,  video  conferencing  capabihties  could  be  enhanced  by  combining  supporting 
services  with  the  collaboration  enabler.  For  example,  in  conferences  that  require  a 
measure  of  privacy,  value-added  encryption  services  could  be  employed.  Supporting 
services,  in  the  form  of  competitive  versions  of  core  management  services  that  employ 
ISDN  D-Channel  Signahng,  could  be  used  to  enable  the  negotiation  of  compression 
algorithms  and  other  features  of  transmission. 
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6.4  MULTI-BITWAY  INTERCONNECTION  EXAMPLE 


An  example  of  the  value  of  and  issues  involved  in  cross-industry  interconnection  of 
bitways  is  shown  in  Figure  6-4.  This  hypothetical  example  illustrates  an  activity  within  the 
education  national  challenge  application  arena  using  the  collaboration  key  enabler.  More 
important,  the  example  highlights  the  variety  of  necessary  bitway  providers  involved  in 
facilitating  the  flow  of  information.  It  depicts  many  problems  in  bitway  interconnectivity 
that  must  be  overcome  to  successfully  deploy  Nil  services  such  as  collaboration.  In 
addition  to  collaboration  and  multibitway  provider  issues,  the  example  illustrates  the 
interdependency  among  choices  of  information  appliances  made  by  users,  choices  of 
apphance  configurations  made  by  manufacturers  and  SPCs,  and  the  characteristics  of 
underlying  bitways. 

This  scenario  was  chosen  because  it  illustrates  some  of  the  issues  involved  in  remote 
interactive  technology.  In  this  example,  a field  biologist  in  Alaska  is  to  demonstrate  a field 
exercise  to  a group  of  students.  The  mobile  information  appliance  used  by  the  biologist  is 
interfaced  into  the  information  infrastructure  through  a low  earth  orbit  (LEO)  satellite 
system.  The  students  are  aU  in  Chicago,  Illinois;  five  are  at  home  with  either  illness  or 
immobilizing  disability,  while  the  remainder  are  in  a classroom.  The  students  at  home  are 
interfaced  through  CATV,  while  those  at  school  are  interfaced  through  a telephone 
company  central  office.  Each  student,  as  well  as  the  teacher,  has  an  individual  information 
appliance  through  which  interactions  with  the  biologist  can  be  supported.  The  teacher’s 
information  apphance  is  also  able  to  monitor  the  students’  activities.  Ah  of  the 
information  appliances  are  capable  of  video  display.  The  biologist’s  camera  is  more 
sophisticated  than  those  of  the  students  and  can  acquire  high-quahty  video  that  can  be 
used  to  record  field  information  and  transmit  it  back  to  the  laboratory  at  the  University  of 
Texas.  The  information  appliances  also  permit  data  interaction  among  the  participants.  In 
addition,  the  biologist  is  able  to  move  data  from  the  laboratory  in  Texas  to  either  her  local 
information  apphance  or  the  appliances  of  the  students.  The  Texas  laboratory  is  tied  in 
through  a public  data  network. 

The  individual  choices  made  by  or  for  participants  wih  be  greatly  influenced  by  the  abihty 
to  reahze  this  scenario.  In  particular,  competitive  marketplace  considerations  among 
products  offered  wih  determine  questions  of  compatibhity  of  equipment,  as  weh  as  system 
procedures.  Service  dependencies,  in  terms  of  the  attributes  cited  in  Section  4,  are 
discussed  below  to  illustrate  their  impact: 

• Information  appliance.  The  choices  of  information  appliances  in  this  scenario 
have  an  effect  on  provision  of  the  services.  The  wireless  information  apphance 
used  by  the  biologist,  for  example,  may  constrain  capabihty  because  of  lower 
bandwidth  and  expectation  of  higher  error  rates  on  the  local  bitway  than  may  be 
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present  in  other  parts  of  the  system.  The  biologist’s  SPC  in  the  field  must  provide 
the  abihty  to  handle  the  compression  and  error  codes  used  in  the  biologist’s 
information  apphance  and  adapt  these  for  use  in  the  wider  network  contexts  if 
communication  is  to  take  place  at  all.  Similarly,  if  the  students  at  home  are  using  a 
low-cost  information  appliance  with  limited  capabilities  acquired  principally  for 
entertainment  purposes,  there  may  be  some  constraint  on  their  interactive 
capabilities. 
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Figure  6-4.  A Remote  Interactive  Education  Example. 


• Content.  The  SPC  in  Chicago  will  be  expected  to  ensure  that  the  format  of  the 
data  matches  the  characteristics  of  the  different  information  appliances  used  by  the 
students.  The  point  at  which  video  format  conversion  takes  place  will  have  to  be 
determined  by  these  providers  according  to  commercial  arrangements. 

• Protocol.  The  protocols  for  interaction  among  the  participants  offer  other 
complications  of  choice.  The  mobile  information  appliance  the  biologist  is  using 
may  employ  separate  protocols  for  data,  video,  and  voice  without  multiplexing 
them,  each  on  a separate  satellite  subchannel,  because  of  commercial  decisions  of 
the  information  appliance’s  manufacturer.  The  students’  information  appliances  at 
the  school  may  all  expect  a protocol  in  which  the  data  types  are  integrated,  and 
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may  have  software  to  do  the  demultiplexing.  This  situation  reflects  individual 
choices  made  by  the  biologist,  the  school  board,  the  information  apphance 
manufacturers,  and  the  SPC.  At  another  level,  if  the  satellite  network  uses  a 
different  naming  and  addressing  structure  from  that  of  the  telephone  network  and 
the  CATV  network,  there  must  be  some  way  of  resolving  addresses  to  enable 
routing  information  to  the  appropriate  recipient(s).  In  the  Nil,  these  problems 
would  be  addressed  and  resolved  through  the  Nil  IP. 

• Bitways.  In  addition  to  the  above,  the  SPC  must  adapt  the  information  appliances 
connected  to  the  various  bitways  involved.  In  the  example,  the  CATV  network 
interconnects  via  an  intercarrier  satellite  network  with  the  public  data  network 
hosting  the  biologist’s  laboratory  server.  If  the  CATV  company,  usually  a local 
company,  does  not  normally  do  business  with  the  satelhte  carrier,  then  a business 
haison  must  be  established.  The  SPC  needs  to  make  similar  arrangements  with  the 
public  data  network.  The  CATV  company  may  already  have  business 
arrangements  with  the  local  telephone  company.  It  will  then  be  necessary  to 
negotiate  adaptations  of  signaling,  physical  layer  framing,  hnk  protocols,  error 
characteristics,  addressing  and  routing,  tariffing,  etc.  These  ’wiU  be  insurmountable 
problems  if  the  various  carriers’  technical  interface  descriptions  are  not  available. 
However,  there  is  a question  as  to  which  party  does  the  task  of  adaptation.  If  the 
adaptation  is  to  be  done  by  the  CATV  company,  because  of  its  size  and  local 
flavor,  it  may  not  be  capable  of  the  heavy-duty  adaptation  required.  Is  the 
adaptation  then  the  responsibihty  of  the  selected  intercarriers?  Does  the  CATV 
company  try  to  get  the  local  telephone  company  to  do  the  adaptation,  under  the 
assumption  that  it  has  the  capabihty?  Among  the  four  SPCs  and  the  intercarriers, 
it  is  not  clear  who  is  responsible  for  the  end-to-end  management  of  the 
collaboration.  This  end-to-end  coordination  is  particularly  significant  when  fault 
isolation  and  problem  resolution  become  necessary. 

The  situations  described  above  raise  some  serious  questions  regarding  roles  and  pohcy. 
For  example,  in  the  case  of  the  students  at  home,  should  there  be  a capabihty  in  the 
information  appliance  to  meet  educational  needs?  Who  should  provide  such  a capabihty, 
if  it  is  lacking?  Should  anyone  provide  it  if  it  is  not  available?  Should  SPCs  be 
responsible  for  knowing  and  supporting  ah  formats  in  common  use,  even  if  not  in  their 
business  interest?  Should  they  be  responsible  for  finding  out  about  them?  If  so,  under 
what  circumstances?  Who  would  provide  such  information?  What  mechanisms  would  be 
available  to  enable  scenarios  similar  to  this  (e.g.,  in  terms  of  formats,  interconnections,  cah 
management),  and  who  would  be  responsible  for  providing  such  mechanisms?  These 
questions  wih  have  to  be  addressed  by  appropriate  groups  within  government,  industry, 
and  academe. 
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6.5  MOSAIC,  A TOOL  FOR  INFORMATION  DISCOVERY  AND  RETRIEVAL 


In  this  example,  we  examine  Mosaic,  an  interactive  application  for  finding  and  retrieving 
information  over  the  Internet.  Developed  at  the  National  Center  for  Supercomputing 
Applications  [5],  Mosaic  utilizes  current  technology  and  is  available  for  use  today. 
Mosaic  integrates  a collection  of  search  and  retrieval  services  offered  on  the  Internet  and 
enables  the  utilization  of  these  services  via  a uniform  interface.  This  integration  of 
dissimilar  local  and  remote  services  behind  a common  interface  constitutes  the  underlying 
paradigm  of  Mosaic.  Similar  paradigms  will  also  underlie  future  Nil  applications.  The 
integration  of  Internet  services  in  Mosaic  requires  resolving  issues  similar  to  those  that 
must  be  resolved  to  implement  Nil  applications.  In  this  example,  the  discussion  of 
integration  issues  is  presented  in  terms  of  service  attributes  that  are  associated  with 
present-day  Internet  services.  The  example  also  offers  a view  of  future  Mosaic-like, 
search  and  retrieval  applications  that  use  digital  library  enabling  services  and  selected 
supporting  services. 

Mosaic  integrates  a variety  of  present-day  Internet  services  such  as  the  World  Wide  Web 
(WWW),  Gopher,  Archie,  and  remote  file  transfer  (FTP)  [6].  The  integration  of  these 
services  is  transparent  to  the  user  who  initiates  various  operations  through  Mosaic's 
hypertext  interface.  Mosaic  provides  access  to  remote  directory  services — such  as 
Archie — to  identify  the  location  of  information  resources  on  the  Internet.  Selected 
resources  may  then  be  accessed  using  Internet  facilities  for  remote  access  such  as  FTP. 
Using  hypertext  browsing  and  retrieval  services,  the  user  can  retrieve  multimedia  items 
from  servers,  including  text,  sound,  image,  and  video.  Like  most  long-standing 
applications  on  the  Internet,  Mosaic  treats  information  resources  as  files  that  can  be 
transparently  transferred  using  a variety  of  protocols  such  as  remote  file  transfer  (FTP) 
services  or  using  a distributed  file  system.  The  software  transparently  invokes  FTP 
services  to  retrieve  selected  files  from  a remote  site.  Mosaic  also  includes  transparent 
access  to  programs  that  permit  audio  playback,  image  display,  and  movie  viewing. 

The  notion  of  service  attributes  is  useful  in  organizing  the  discussion  of  interoperability 
issues  that  had  to  be  resolved  to  integrate  the  underlying  Internet  services  used  by  Mosaic. 
For  instance,  to  access  and  retrieve  information  from  the  World-Wide  Web  (WWW), 
which  is  a collection  of  interconnected  information  hypertext  servers  and  repositories. 
Mosaic  utihzes  common  protocols  and  processes  data  structured  in  standardized  data  and 
content  formats.  Therefore,  the  following  service  attributes  are  most  important  aspects  of 
the  Internet  services  used  by  Mosaic: 
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• Protocol.  WWW  clients  such  as  Mosaic  use  a collection  of  protocols  to  access 
information  "on  the  web."  The  Hypertext  Transport  Protocol  (HTTP)  is  the  main 
protocol  used  to  retrieve  WWW  hypertext  pages  through  a server.  The  HTTP 
protocol  supports  both  search  and  retrieval  (including  index  searches)  and  is  faster 
than  FTP  for  document  retrieval  (because  HTTP  does  not  require  authentication). 
The  File  Transfer  Protocol  (FTP)  is  used  for  retrieving  files  from  remote  network 
nodes  that  support  FTP  but  not  HTTP. 

• Data  and  Content  Format.  The  mainstay  of  data  in  WWW  are  pages  of 
hypertext  defined  in  the  Hypertext  Markup  Language  (HTML),  which  is  based  on 
Standardized  General  Markup  Language  (SGML).  A typical  data  structure 
accessed  through  WWW  is  a hypertext  page  that  has  links  to  other  hypertext  pages 
and  sound,  image,  and  video  files. 

To  present  the  contents  of  a multimedia  file  to  the  user.  Mosaic  first  determines  the  type 
of  data  in  the  file  by  examining  either  a file  header  describing  the  file  content  or  the  file 
extension.  Mosaic  then  invokes  the  appropriate  subsystem,  such  as  an  audio  or  video 
player,  to  process  the  file. 

Mosaic's  current  capabihties  can  be  viewed  as  an  early  version  of  what  future  applications 
based  on  Nil  services  will  one  day  provide.  For  example,  to  search  for  information 
located  in  federated  systems  of  digital  hbraries.  Nil  applications  may  employ  selected 
aspects  of  digital  hbrary  enabling  services  integrated  with  hypertext  facilities,  knowledge- 
based  query  processing  support  services  and  underlying  directory  service,  remote  access, 
and  file  transfer  facihties.  (It  should  be  noted  that  Mosaic  can  now  be  used  to  access 
present-day  digital  libraries  in  the  manner  described  in  the  paragraphs  above.) 

Using  an  information  apphance  that  accepts  voice  input,  a researcher  could  verbally 
request  information  about  a particular  topic,  such  as  technical  literature  on  a particular 
agricultural  technique.  A speech  recognizer  converts  voice  to  an  internal  representation 
based  on  an  extended  SQL  format.  The  application  system  could  then  employ  knowledge- 
based  query  processing  support  services  to  analyze  the  query  much  in  the  way  a hbrarian 
at  a reference  desk  would.  The  original  request  would  be  checked  for  semantic 
consistency  and  reformulated  if  the  conditions  are  too  broad  or  narrow.  To  reformulate 
the  query,  production  rules  provided  by  the  support  service  could  be  used  that  contain  or 
use  knowledge  about  the  researcher's  subject  area.  This  knowledge  includes  taxonomies 
of  agricultural  terms,  fists  of  libraries  likely  to  contain  agricultural  information,  and 
statistics  on  the  amount  of  information  likely  to  be  yielded  in  searches  on  particular  terms. 
These  rules  could  be  used  to  substitute,  add,  or  delete  conditions  in  the  query  or 
decompose  the  query  into  smaller  queries.  The  reformulated  query  could  then  be  targeted 
for  libraries  obtained  from  a directory  service  that  are  most  likely  to  yield  useful 
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information.  Similar  industry-specific  support  services  utilizing  knowledge-based  query 
processing  methods  could  be  developed  for  many  subject  areas  and  incorporated  into 
applications. 

Prior  to  actual  access  to  libraries,  the  user  will  most  likely  be  provided  with  an  estimate  of 
the  cost  of  further  use  of  services.  If  the  user  elects  to  proceed,  supporting  services  based 
on  digital  cash  would  be  employed  to  enable  electronic  payment.  The  application  system 
could  then  proceed  to  hnk  to  selected  hbraries,  using  an  underlying  service  based  on  a 
protocol  that  supports  transmission  of  user  queries.  The  query  would  be  applied  within 
each  hbrary.  The  user  would  be  presented  with  a set  of  literature  sources  to  examine, 
possibly  with  an  evaluation  of  which  sources  are  more  likely  to  be  useful.  Digital  hbrary 
facilities  could  be  used  to  access  particular  books  or  articles,  and  hypertext  facilities  would 
permit  browsing  the  actual  text  itself.  If  a number  of  extensive  text  sources  have  been 
found  and  the  user  wishes  to  explore  this  collection,  knowledge  discovery  support  services 
could  be  invoked  through  the  application  interface  to  automatically  browse  the  combined 
text  from  these  sources.  The  discovery  tools  could  further  focus  or  expand  the  query  or 
use  statistical  classification  methods  to  find  new,  possible  unanticipated  data  related  to  the 
original  request. 

As  in  Mosaic,  the  paradigm  of  integrated  services  hidden  behind  a uniform  interface  is  a 
sahent  aspect  of  the  underlying  structure  of  this  application.  A standardized  query 
language,  such  as  extended  SQL,  would  be  used  to  query  individual  hbraries,  eliminahng 
the  necessity  of  conversion  between  query  languages  associated  with  particular  hbrary 
systems.  To  integrate  the  various  supporting  services  discussed  above,  the  digital  hbrary 
enabling  services,  and  the  underlying  file  transfer  services,  intermediaries  would  be 
employed  where  necessary  to  convert  between  different  formats. 
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7.  OPEN  ISSUES 


A number  of  issues  identified  during  the  course  of  this  study  remain  to  be  addressed.  The 
issues  cited  here  are  those  the  government  can  help  resolve  through  law,  regulation,  or 
policy.  Other  service-related  issues  are  omitted  from  this  discussion  because  the  authors 
believe  that  normal,  competitive  market  forces  will  evolve  effective  resolutions.  This 
discussion  does  not  undertake  to  surface  all  possible  legal  and  policy-related  issues  at 
once.  Instead,  it  concentrates  on  a few  key  issues  that  will  constrain  the  technical 
approaches  to  Nil  service  interfaces  and  service  implementation.  This  collection  of  issues 
is  a “starter  set,”  to  which  additions  suggested  by  outside  reviewers  are  particularly 
welcome. 

Many  issues  arise  from  the  multiple  roles  of  government  with  respect  to  activities  in  the 
NIL  These  roles  include  provider  of  public  services,  protector  of  consumers,  protector  of 
the  indigent  and  other  disadvantaged  persons,  defender  against  hostile  attack,  codifier  of 
standard  commercial  practices  and  legal  standards  of  proof,  investigator  and  prosecutor  of 
criminals,  protector  of  inventors  and  authors,  educator  of  the  citizenry,  and  sponsor  of 
advanced  research  and  development  (R&D)  for  the  Nil. 

In  the  discussion  below,  issues  related  to  security,  privacy,  universal  addressing,  and 
anonymous  use  are  first  addressed,  followed  by  other  issues.  The  final  subsection  ranks 
the  issues  presented  in  order  of  importance. 


7.1  SECURITY,  PRIVACY,  UNIVERSAL  ADDRESSING,  AND  ANONYMOUS 
USE 


7.1.1  General  Discussion 

Users  are  generally  willing  to  assume  a limited  risk  in  order  to  use  public  networks.  If 
they  perceive  the  level  of  risk  as  too  high,  they  avoid  a network  or  restrict  its  use  to  low- 
valued, incidental  activity.  Risks  can  be  avoided  or  mitigated  by  technical  means,  by 
“hedges”  including  insurance,  and  by  civil  and  criminal  penalties  for  various  types  of 
misuse.  Technical  means  of  protection  include  identification  and  authentication  of  users 
and  service  providers,  controls  to  prevent  unauthorized  access  to  information  or 
misdelivery  of  messages,  use  of  cryptography  to  hide  information  content  or  avoid 
subsequent  repudiation  of  documents  and  messages,  safety  inspections  of  information 
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appliances  connected  to  networks,  and  monitoring  of  network  activity  for  suspicious 
patterns  of  use. 

The  desire  for  safety  in  using  public  networks  must  be  counterbalanced  against  legal  and 
cultural  principles  relating  to  privacy.  Neither  the  government  nor  any  commercial 
provider  of  core  network  services  ought  to  inquire  into  the  spiritual,  political,  or  other 
noncommercial  purposes  for  which  users  request  services,  as  a condition  for  providing 
services.  Sometimes  these  purposes  are  suggested  in  the  content  of  information  provided 
by  the  user  and  stored  in  persistent  service  objects.  At  other  times,  purposes  for  use  can 
be  inferred  from  data  such  as  toll  records,  call  setup  information,  and  audit  logs. 
Information  indicative  of  the  purposes  for  service  requests  that  is  kept  as  part  of  a service 
or  for  its  orderly  management  should  not  be  disclosed  without  the  permission  of  the 
service  requester,  except  in  response  to  a subpoena,  search  warrant  for  probable  cause, 
similar  court  order,  or  as  authorized  by  law. 

On  the  other  hand,  an  inquiry  into  the  spiritual,  political,  or  other  purposes  for  requesting 
a value-added  service  may  be  indispensable  to  providing  the  service.  In  such  cases,  users 
expect  to  be  informed  of  the  uses  that  wiQ  be  made  of  such  information  before  requesting 
a service. 

Another  principle  is  that  neither  the  government  nor  commercial  providers  of 
infrastructure  services  can  discriminate  on  any  illegal  basis  in  denying  or  delaying  services. 
Service  providers  may,  of  course,  deny  service  to  users  who  are  not  current  in  payment  of 
tolls,  tariffs,  or  fees  for  services,  or  who  do  not  comply  with  necessary  legal  restrictions  in 
the  use  of  Nil  services. 


7.1.2  Issue:  Universal  Security  Policy 

To  guarantee  that  risk  does  not  exceed  some  acceptable  maximum,  a comprehensive 
security  pohcy  is  needed.  Such  a pohcy  would  ensure  that  a safety  net  of  basic  protection 
mechanisms  is  in  place  from  the  outset,  and  supported  by  effective  legislation.  From  this 
baseline,  more  sophisticated  value-added  supplementary  services  could  be  developed, 
implementing  more  rigorous  policies.  The  core  security  pohcy  could  address 
identification,  authentication,  ownership,  sensitivity  and  protection  markings,  maintenance 
of  audit  trails  on  disclosures,  rights  to  challenge  and  correct  recorded  information,  and 
protection  of  the  information  infrastructure  from  various  threats  (hostile  forces  and 
criminals,  disasters,  and  mishaps). 

The  alternative  to  such  a universal  core  policy  is  to  allow  different  communities  of  interest 
to  establish  unique  policies  and  associated  security  services.  Subsequent  standardization 
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activities  could  pare  the  number  of  different  services  down  to  a manageable  few. 
Intermediaries  operating  at  the  services  layer  could  then  negotiate  pair-wise  interactions 
between  conceptually  similar  protection  services  that  were  wilhng  to  trust  one  another. 
Services  implemented  according  to  very  dissimilar  policies  would  probably  not  be  trusted 
to  interoperate. 

7.1.3  Issue:  Registration  and  Licensing 

As  a general  principle,  registration  of  ordinary  users  should  be  simple  and  nonrestrictive, 
so  as  not  to  interfere  with  the  rights  of  free  speech  and  peaceable  assembly.  Proof  of 
identity  will  be  needed  to  use  billable  services,  at  least  until  some  form  of  “digital  cash” 
can  be  implemented.  Certain  noncommercial  transactions  may  also  need  to  be  restricted 
to  known  persons. 

In  some  cases,  the  privilege  of  offering  a service  or  connecting  an  information  apphance 
might  be  Licensed  in  the  interest  of  overall  security  and  privacy.  The  prerequisites  for 
offering  a service  or  connecting  an  information  appliance  might  include  the  following: 

• Demonstration  of  fmancial  responsibihty  for  any  possible  damages,  e.g.,  proof  of 
insurance  or  posting  of  bond. 

• Inspection  by  a competent  governmental  body  or  hcensed  laboratory  to  determine 
that  implementation  of  a service  or  information  apphance  accords  with  generally 
accepted  safe  practices. 

Any  restrictions  on  hcensing  of  service  providers  must  avoid  censorship  of  information 
content  under  the  guise  of  ensuring  reputable  business  practices  to  protect  the  public. 

Once  a provider  offers  a service  to  the  general  public,  particularly  a core  service,  a 
condition  for  a hcense  might  be  that  the  provider  not  withdraw  the  service  without  proper 
advance  notice. 


7.1.4  Issue:  Anonymous  Activity 

There  is  a large  realm  of  legitimately  anonymous  use  of  services,  pseudonymous 
publication,  and  other  activity  subject  to  expectations  of  privacy.  Possibilities  for 
reconciling  this  need  with  the  need  to  identify  and  authenticate  users  are  as  follows: 
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• Identify  and  authenticate  users  to  a high  level  of  trust,  and  provide  by  policy,  law, 
or  regulation  that  identification  be  “forgotten”  for  specified  types  of  legitimately 
anonymous  transactions. 

• Identify  and  authenticate  users  to  varying  levels  of  trust  that  depend  on  the 
information  appliances,  the  mechanisms  and  techniques  being  used  at  the 
information  apphance  access  point,  and  the  degree  of  disclosure  agreed  to  by  the 
user  for  a session.  Particular  services  will  either  complete  or  deny  requested 
transactions  based  upon  the  level  of  trust  in  identity. 

Some  users  may  wish  to  ignore  messages  from  anonymous  sources,  publications  by 
unidentified  authors,  and  “offensive”  material,  whether  or  not  pubhshed  anonymously.  To 
what  extent  must  the  nature,  content,  or  authorship  of  messages  and  publications  be 
accurately  characterized  in  information  transfer  protocols  and  document  indexes?  Users 
may  wish  to  filter  out  unsolicited  commercial  advertisements,  religious  tracts, 
pornographic  materials,  or  other  kinds  of  information.  Possible  approaches  include  the 
following: 

• Require  that  “subject  hues”  and  indexing  entries  contain  codes  characterizing 
information  content  and  categories  of  authorship.  This  would  necessitate  precise 
legal  definition  of  categories  of  potentially  offensive  information.  Criminal  or  civU 
penalties  could  apply  to  omission  or  to  deceptive  labehng.  Anonymous  authorship 
of  certain  categories  of  potentially  offensive  information,  such  as  commercial 
advertising,  might  be  prohibited. 

• Depend  on  the  marketplace  to  offer  “safe  havens”— services  guaranteed  not  to 
contain  categories  of  potentially  offensive  information.  If  sufficient  demand  exists 
for  advertising-free  and  G-rated  services  (for  a price),  the  marketplace  whl  dehver 
them. 

7.1.5  Issue:  Security  Labeling 

At  service  interfaces,  it  is  technically  possible  to  “mark”  information  to  allow  one  service 
to  tell  another  service,  an  application,  or  an  information  appliance  about  security 
requirements.  Do  such  markings,  when  included,  need  to  be  standardized?  One 
possibihty  is  to  “register”  sensitivity  markings  defined  by  those  communities  having  an 
interest  in  protecting  their  own  information.  The  association  of  a sensitivity  marking  with 
requisite  protection  mechanisms  would  then  have  to  be  negotiated  with  the  service 
provider. 
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An  alternative  is  to  agree  on  protection  markings  indicating  the  level  and  nature  of 
technical  protection  that  must  be  given  to  the  information,  for  example,  encryption 
strength,  content  and  retention  of  audit  trails,  and  access  hmitations.  The  reasons  for 
requiring  a particular  strength  of  protection  would  not  need  to  be  standardized  across 
interfaces. 

For  infrastructure  services,  will  it  be  necessary  to  “mark”  information  to  allow  one  service 
to  tell  another  about  security  requirements  and  to  interface  with  applications?  If  so,  what 
will  be  the  nature  of  this  marking? 

7.1.6  Issue:  Universal  Addressing 

The  Nil  will  evolve  from  the  public  switched  telephone  network,  the  interconnection  of 
various  private  computer  networks,  the  Internet  (possibly  partitioned  by  “fu*ewaU”  security 
processors),  wireless  networks,  and  entertainment  cable  networks.  The  convergence  to 
bidirectional,  interactive  communications  will  proceed  at  a rate  dictated  by  the  protection 
of  existing  investments  in  information  appliances,  which  serve,  for  example,  a biUion 
telephone  users  worldwide  and  include  20  milhon  facsimile  machines. 

Effective  use  of  the  Nil  demands  that  it  be  easy  to  address  information  to  any  user  at  any 
information  appliance  in  any  location  that  is  supported  by  the  infrastructure. 

In  the  absence  of  public  pohcy  on  addressing,  the  heterogeneous  networks  forming  the 
Nil  are  most  likely  to  have  dissimilar  addressing  schemes.  Whenever  the  pool  of 
addresses  in  one  scheme  (e.g.,  10-digit  numbers  for  telephony,  32-bit  addresses  for  the 
Internet  Protocol)  is  exhausted  or  too  difficult  to  administer,  addressing  will  be  extended 
in  a manner  similar  to  that  previously  used. 

Should  there  be  a public  pohcy  goal  requiring  or  encouraging  the  heterogeneous 
constituent  networks  to  adopt  a common,  universal  addressing  scheme?  Many  people  will 
be  reluctant  to  support  such  a goal  on  privacy  grounds.  If  there  is  a universal  address,  will 
it  be  based  upon  identifying  an  individual  user  or  organizational  unit  (wherever  located 
and  using  whatever  information  appliance)?  Or  will  the  address  be  that  of  an  access 
“port”  (by  whomever  used  with  whatever  appliance)?  Or  will  the  address  be  that  of  an 
instance  of  an  apphance  (by  whomever  and  wherever  used)?  Whichever  approach  is 
taken,  directory  services  and  intermediaries  can  still  make  the  three-way  associations  of 
user,  appliance,  and  access  point. 


7-5 


7.2  OTHER  ISSUES 


7.2.1  Sufficiency  of  Current  Laws  to  Curtail  Undesired  Behavior 

There  is  concern  that  segments  of  the  population  may  be  denied  or  limited  access,  but 
there  is  an  opposing  problem  that  those  with  access  may  be  subject  to  new  threats  and 
habihties.  The  following  are  examples  of  areas  where  existing  laws  on  mail  fraud,  wire 
fraud,  privacy,  and  reporting  may  not  be  easy  to  apply: 

• Fraud.  New  forms  of  fraud  are  devised  each  day.  The  Nil  will  undoubtedly  be 
used  as  a mechanism  for  fraud  in  the  future,  especially  if  protection  against 
masquerade  is  not  provided. 

• Surveillance.  In  the  past,  if  a network  switching  element  were  compromised,  this 
meant  the  potential  for  free  service  and  transaction  monitoring.  In  the  future,  it 
could  mean  the  potential  to  monitor  the  activities  of  an  entire  household  or 
business  through  a sophisticated  information  appliance.  As  consumer  transactions 
become  more  automated,  it  also  becomes  easier  to  collect  and  aggregate  the 
behavior  and  interests  of  individuals.  Although  this  may  be  considered  a useful 
service  by  some  customers,  others  consider  aggregation  of  even  a httle  personal 
detail  without  prior  consent  of  the  individual  to  be  intrusive.  If  the  identity  of 
persons  can  be  inferred  from  addressing  and  routing  information,  wireless 
communications  involving  small  ceU  sizes  may  divulge  the  private  movements  and 
whereabouts  of  a person  even  if  the  data  content  is  encrypted. 

• Red-lining.  Quick  and  comprehensive  access  to  a patient’s  medical  records  is  an 
important  aspect  of  health  care  dehvery.  Yet  access  to  such  information  by 
insurers  may  limit  an  individual’s  ability  to  obtain  or  retain  health,  life,  and  other 
types  of  insurance.  Other  forms  of  insurance  red-lining  may  be  based  on  behavior 
inferred  from  commercial  transactions. 

• Accident.  While  ease  of  use  is  the  goal  of  most  software,  it  is  seldom  achieved. 
One  can  easily  envision  a consumer  intending  to  purchase  one  item  and  instead 
ending  up  with  another.  It  is  also  not  clear  how  one  returns  a digital  item  or 
service. 


7.2.2  Standards  of  Proof  for  Resolving  Conunercial  Disputes 

Technical  standards  ensuring  nonrepudiation  of  messages  and  documents  by  “digital 
signature”  and  time  stamping  must  be  accepted  by  aU  courts  at  the  various  levels  where 
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commercial  disputes  are  settled.  Rules  of  evidence  establishing  the  primacy  of  electronic 
copies  with  respect  to  paper  copies  of  documents  must  be  reasonably  uniform  among 
different  courts.  Without  uniform  treatment,  electronic  commerce  will  be  seriously 
inhibited.  Since  case  law  is  slow  to  evolve,  statutory  standardization  seems  necessary. 
The  Uniform  Commercial  Code,  appropriately  modified,  could  be  a vehicle  to  encourage 
the  states  to  adopt  compatible  standards  of  proof. 

7.2.3  Information  Appliance  Interfaces 

Should  all  wired  information  appliances  use  a common  physical  connection  (universal  plug 
and  socket)?  Some  possibilities  are  as  follows: 

• Define  a common  plug  and  socket,  with  the  goal  that  ah  information  appliances 
wih  eventually  use  it.  One  or  more  “wires”  into  a location  wih  fan  out  into  a 
number  of  identical  sockets.  “Plug  and  play”  techniques  wih  be  needed  to  conduct 
a census  of  devices  attached  at  a location,  to  install  device-related  software,  and  to 
make  avahable  the  correct  rendering  and  translation  capabihties  for  services 
interacting  with  the  information  appliances. 

• Use  different  types  of  plugs  and  sockets  for  different  kinds  of  information 
appliances,  as  long  as  matching  a plug  to  a socket  is  obvious  through  the  use  of 
distinctive  shapes  and  matching  icons,  and  it  is  physicaUy  impossible  to  insert  a 
plug  into  a mismatched  socket.  One  or  more  wires  into  a location  whl  fan  out  to  a 
heterogeneous  set  of  sockets.  More  sockets  whl  be  needed,  but  interfacing 
techniques  wih  be  simpler. 

• Since  near-term  solutions  probably  involve  using  relatively  cheap  plug  adapters  or 
black  boxes,  let  evolution  in  the  marketplace  occur  without  early  definition  of  any 
standards. 


7.3  RANKING  OF  ISSUES  PRESENTED 

The  eight  issues  presented  above  can  be  ranked  in  importance  based  on  the  immediacy  of 
the  need  for  their  resolution  and  the  potential  adverse  consequences  of  assuming  an 
outcome  that  does  not  hnahy  result.  Comments  by  reviewers  may  result  in  a ranking 
different  from  the  following: 

1.  Universal  Addressing  (Section  7.1.6).  We  are  about  to  exhaust  Internet  Protocol 
addresses,  as  well  as  10-digit  telephone  numbers.  If  we  do  not  act  soon  on  universal 


7-7 


addressing,  a rare  opportunity  will  be  lost.  Electronic  commerce  may  be  slow  to 
develop  without  universal  addressing.  Government  action  will  be  instrumental  in 
articulating  this  requirement. 

2.  Anonymous  Activity  (Section  7.1.5).  This  is  an  area  where  strong  emotions  figure. 
If  public  outcry  forces  a legislative  mandate  to  reverse  course,  retrofitting  of 
architectural  features  to  protect  or  prevent  anonymity  could  be  costly. 

3.  Universal  Security  Policy  (Section  7.1.2).  The  longer  the  wait,  the  more  difficult  it 
will  be  to  implement  a universal  security  policy.  By  waiting  too  long,  the  question  is 
resolved  in  favor  of  no  universal  policy. 

4.  Standards  of  Proof  for  Resolving  Commercial  Disputes  (Section  7.2.2). 

Electronic  commerce  for  other  than  trivial  transactions  cannot  achieve  its  potential 
until  progress  is  made  on  this  front,  although  other  areas  are  not  much  impacted. 

5.  Registration  and  Licensing  (Section  7.1.3).  The  formulations  of  particular 
approaches  to  registration  or  licensing  depend  on  how  the  issue  of  security  policy  is 
resolved.  This  is  another  emotional  issue,  but  has  less  impact  on  technical  protocols 
and  service  interfaces. 

6.  Information  Appliance  Interfaces  (Section  7.2.3).  The  marketplace  may,  if  left 
unencumbered  by  policy,  devise  one  or  a manageable  few  plug-and-socket 
conventions,  but  such  an  outcome  is  not  certain.  The  economic  impact  of  a 
heterogeneous  outcome  could  be  substantial,  but  would  be  dispersed  across  a large 
population.  Failing  to  come  to  grips  with  this  issue  would  result  in  a year-for-year  slip 
in  achieving  a standard  solution. 

7.  Security  Labeling  (Section  7.1.5).  Interoperability  of  protection  services  will  entail 
overly  complex  intermediary  services  if  there  are  no  common  concepts  for  labeling. 

8.  Sufficiency  of  Current  Laws  to  Curtail  Undesired  Behavior  (Section  7.2.1). 

Hostile  action,  fraud,  negligence,  invasion  of  privacy,  and  other  undesired  behaviors 
win  never  be  totally  eliminated.  A substantial  reexamination  of  current  laws  is  needed 
to  provide  a solid  legal  basis  that  wiU  be  effective  against  “bad  guys” — the  inventive 
criminal  and  the  negligent.  Electronic  commerce  and  certain  life-critical  services  may 
be  slow  to  develop  if  legal  development  lags. 
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ACRONYMS  AND  DEFINITIONS 


A.  ACRONYMS  AND  DEFINITIONS 


A.l  ACRONYMS 


AAL 

ATM  Adaptation  Layer 

ADSL 

Asymmetric  Digital  Subscriber  Loop 

AFS 

Andrew  File  System 

AM-VSB 

Amplitude  Modulation — ^Vestigial  Side  Band 

API 

Application  Programming  Interface 

APP 

Application  Portability  Profile 

ASN.l 

Abstract  Syntax  Notation  1 

ATM 

Asynchronous  Transfer  Mode 

B-ISDN 

Broadband  ISDN 

BRI 

Basic  Rate  Interface 

CATV 

Cable  Television 

CCITT 

see  ITU 

GIF 

Common  Intermediate  Format 

CLNP 

Connectionless  Network  Protocol 

CORBA 

Common  Object  Request  Broker 

DCE 

Distributed  Computing  Environment 

DCT 

Discrete  Cosine  Transform 

DISA 

Defense  Information  Systems  Agency 
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DME 

DoD 

EDI 

FCC 

PCS 

EEC 

FTP 

FTTC 

HDTV 

HTML 

HTTP 

IDL 

lEC 

HTF 

ISDN 

ITU 

JPEG 

LAN 

LATA 

LEC 

LEO 


Distributed  Management  Environment 
Department  of  Defense 
Electronic  Data  Interchange 
Federal  Communications  Commission 
Fiber  Channel  Standard 
Forward  Error  Correction 
File  Transfer  Protocol 
Fiber  to  the  Curb 
High-Definition  Television 
Hypertext  Markup  Language 
Hypertext  Transfer  Protocol 
Interface  Definition  Language 
Interexchange  Carrier 
Information  Infrastructure  Task  Force 
Integrated  Services  Digital  Network 

International  Telecommunications  Union,  formerly  International  Telephone 
and  Telegraph  Consultative  Committee  (CCITT) 

Joint  Photographies  Expert  Group 

Local  Area  Network 

Local  Access  Transport  Area 

Local  Exchange  Carrier 

Low  Earth  Orbit 


A-2 


MPEG 

Motion  Pictures  Experts  Group 

N/B-ISDN 

Narrowband/Broadband  ISDN 

N-ISDN 

Narrowband  ISDN 

NFS 

Network  File  System 

NH 

National  Information  Infrastructure 

Nil  IP 

National  Information  Infrastructure  Interworking  Protocol 

NIST 

National  Institute  of  Standards  and  Technology 

NNTP 

Network  News  Transfer  Protocol 

NTSC 

National  Television  Standard  Code 

OAM 

Operations,  Administration  And  Management 

OC-X 

Optical  Carrier  X (where  X is  a numeric) 

ODN 

Open  Data  Network 

OMG 

Object  Management  Group 

OSF 

Open  Software  Foundation 

OSI 

Open  Systems  Interconnection 

PBX 

Private  Branch  Exchange 

PCS 

Personal  Communication  System 

POTS 

Plain  Old  Telephone  Service 

QAM 

Quadrature  Amplitude  Modulation 

QOS 

Quality  of  Service 

QPSK 

Quadrature  Phase  Shift  Keying 

R&D 

Research  and  Development 
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RAID 

Redundant  Arrays  of  Inexpensive  Disks 

RBOC 

Regional  Bell  Operating  Company 

RFQ 

Request  For  Quotations 

SCP 

Service  Control  Point 

SCSI 

Small  Computer  System  Interface 

SDH 

Synchronous  Data  Hierarchy 

SGML 

Standardized  General  Markup  Language 

SNA 

Systems  Network  Architecture 

SONET 

Synchronous  Optical  Network 

SPC 

Service  Provider  to  the  Customer 

SQL 

Structured  Query  Language 

SS7 

Signahng  System  7 

TAFIM 

Technical  Architecture  Framework  for  Information  Management 

TBD 

To  Be  Determined 

TCP/IP 

Transmission  Control  Protocol/Intemet  Protocol 

TMN 

Telecommunications  Management  Network 

UDP 

User  Datagram  Protocol 

UTP 

Unshielded  Twisted  Pair 

VDT 

Video  Dial  Tone 

VOD 

Video  on  Demand 

WAIS 

Wide  Area  Information  Server 

WWW 

World-Wide  Web 
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A.2  DEFINITIONS 


Agent.  See  Intermediary. 

Application.  A specified  collection  of  activities  or  functions  of  an  information  appliance 
or  set  of  appliances,  i.e.,  a “binding”  of  one  or  more  services  on  the  user  interface  to  the 
information  appliance.  An  application  may  persist  over  time,  in  which  case  it  is  reusable, 
or  it  may  exist  for  only  one  instance.  An  application  may  become  a service  if  it  is  offered 
for  use  to  users  other  than  the  owner  through  a standard  interface  with  any  fees 
prearranged.  An  application  implementation  (e.g.,  shrink-wrapped  software)  offered  for 
sale  does  not  make  the  application  a service.  NOTE:  This  is  a definition  that  corresponds 
to  definitions  used  by  the  computer  and  communications  industries.  The  Nil 
“applications”  (i.e.,  national  challenge  application  arenas),  such  as  education, 
manufacturing,  and  health  care,  are  collections  of  applications  as  defined  here. 

Bitway.  The  physical  infrastructure  and  the  access  mechanisms,  interfaces  and  transport 
mechanisms  (often  embodied  in  software)  necessary  for  transmission,  switching  or 
routing,  signaling,  and  related  management  of  digital  data,  with  or  without  format,  across 
the  physical  pathways  of  the  infrastructure.  Current  bitway s are  characterized  by  the 
transport  medium  (e.g.,  cable,  air-link,  fiber)  and  the  business  represented  (e.g., 
entertainment,  telephone,  broadcast  communications).  A bitway  can  be  as  simple  as  a 
point-to-point  private  communications  path  (for  transmission  of  bits  only)  or  as  complex 
as  a public  switched  network  with  aU  its  superset  functions.  The  local  bitway  (“on  ramp” 
to  the  information  superhighway)  is  the  physical  bitway  and  associated  services  from  the 
information  appliance  to  the  information  apphance  access  point.  The  global  bitway 
(“highway”)  is  the  collection  of  physical  paths  and  bitway  services  that  make  up  the 
interior  of  the  Nil,  i.e.,  the  collection  of  networks  available  for  public  usage. 

Broker.  See  Intermediary. 

Common  Services.  A service  that  tends  to  regularize  some  aspect  of  the  service 
environment.  Its  use  must  result  from  a consensus  by  the  parties.  A service  need  not 
conform  to  a “standard”  to  be  common.  For  example,  in  attaching  an  information 
appliance  to  the  infrastructure  through  a service  provider  to  the  customer  (SPC),  certain 
interface  and  interaction  rules  will  be  followed,  or  no  service  access  can  result.  Thus,  the 
information  appliance  and  the  SPC  should  have  a common  view  of  the  services  and  access 
interfaces  provided  to  the  appliance.  The  local  access  provider  chooses,  on  the  basis  of 
business  decisions,  what  interfaces  and  services  will  be  offered.  A user  needs  to  find  an 
information  appliance  that  is  compatible  with  what  the  local  access  provider  supplies. 
Similarly,  a common  means  of  interacting  must  exist  between  the  local  access  provider  and 
other  service  providers  elsewhere  in  the  infrastructure.  Sometimes  this  will  imply  the 
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existence  of  an  intermediary  which  provides  the  commonality  of  interaction  by  pair-wise 
translations.  Ideally,  common  services  should  have  public  specifications  of  their  interfaces 
and  functions.  Formal  standards  typically  meet  this  ideal,  and  many  de  facto  standards  do 
as  well.  Examples  of  services  with  public  specifications  and  their  uses  in  computer-based 
information  systems  may  be  found  in  the  Application  Portability  Profile  (APP)  from  the 
National  Institute  of  Standards  and  Technology  (NIST)  and  the  Technical  Architecture 
Framework  for  Information  Management  (TAFTM)  from  the  Defense  Information  Systems 
Agency  (DISA).  Such  services  are  often  said  to  provide  the  basis  for  “open  systems.”  A 
service  is  “uncommon”  if  it  tends  to  have  specialized  access;  so  that  relatively  few  users 
can  gain  access  to  it.  Uncommon  services  generally  do  not  have  public  specifications  and 
are  often  proprietary  or  private  in  nature,  but  not  aU  proprietary  services  are  necessarily 
uncommon:  IBM’s  Systems  Network  Architecture  (SNA)  is  in  widespread  use,  and  a 
substantial  number  of  third-party  providers,  including  competitors  of  IBM,  produce 
products  that  can  access  SNA.  Access  to  uncommon  services  may  be  mediated  by 
intermediaries,  provided  there  is  sufficient  interest  to  warrant  the  costs  of  offering  an 
appropriate  intermediary. 

Core  Networking  Services.  Services  which  are  for  the  common  use  or  support  of  any 
user  or  application.  These  services  are  unique  in  their  functionality  to  Nil  operation,  and 
because  of  their  criticahty,  consensus  in  their  definition,  specification,  and  implementation 
win  be  highly  desirable,  if  not  mandatory,  if  the  Nil  is  to  function  as  envisioned.  The 
degree  of  commonahty  required  in  these  services  is  a pohcy  question,  beyond  the  scope  of 
this  document. 

Customer.  That  person,  organization,  or  entity  which  receives  services  provided  by  the  NH  or 
its  associated  service  providers.  The  conventional  sense  of  customer  usually  entails  payment 
for  services,  but  the  definition  has  been  broadened  here  to  include  nonpaying  consumers  of 
service  to  avoid  too  corr^lex  a terminology.  Generally,  an  information  appliance  is  not  itself  a 
customer,  but  rather  the  extension  of  the  human  consumer  who  obtains  service  through  the 
appliance. 

Enabler.  See  Key  Enabling  Services 

Information  Appliance.  An  information  appliance  is  any  customer-controlled  device 
through  which  a user  accesses  services  (in  particular,  infrastructure  services).  This 
definition  is  as  inclusive  as  possible  for  use  in  this  document.  It  includes  client  appliances 
as  purchased  by  individuals,  as  well  as  server  appliances.  Client  appliances  are  very 
diverse  and  must  be  cost-effective,  while  server  appliances  need  to  be  scalable. 
Information  apphance  refers,  therefore,  to  such  devices  as  television  receivers,  computers, 
telephones,  facsimile  machines,  wireless  personal  digital  assistants,  and  medical  telemetry 
units.  Sometimes  the  information  appliance  will  require  particular  hardware  or  software. 
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called  service  interface  components,  to  enable  service  from  an  information  appliance 
access  point.  A specified  collection  of  activities  of  an  information  appliance  or  set  of 
appliances  is  called  an  application. 

Information  Appliance  Access  Point.  The  place  where  an  information  appliance 
attaches  to  the  Nil  to  obtain  services.  Typically,  this  will  be  through  some  provider 
associated  with  the  physical  attachment,  for  “wired”  information  appliances,  or  with  the 
“air  hnk”  for  wireless  information  appliances.  In  general,  there  is  no  fixed  way  in  which 
the  access  points  will  be  implemented,  since  this  depends  upon  the  business  of  the 
implementor.  For  example,  if  the  appliance  is  on  a private  network  attached  to  the  Nil  via 
a privately  owned  private  branch  exchange  (PBX)  tied  to  a satelhte  carrier,  the  PBX  is 
considered  to  be  a part  of  the  access  point  along  with  the  satellite  company’s  ground 
station.  Similarly,  an  ISDN  local  area  network  (LAN)  bridge  that  connects  a locally- 
managed,  private  LAN  to  ISDN  provided,  say,  by  a Regional  BeU  Operating  Company 
(RBOC),  so  that  remote  users  can  get  into  the  LAN,  is  considered  to  be  part  of  the  access 
point,  along  with  the  LAN  system  and  the  RBOC’s  central  office. 

Infrastructure.  In  the  simplest  case,  an  infrastructure  is  an  electronic  or  optical  network 
(bitway)  intended  to  interconnect  devices  to  support  the  passage  or  usage  of  information. 
In  the  more  general  case,  an  infrastructure  is  a set  of  bitways  (coordinated  and  seamless, 
or  not),  with  a set  of  basic  services,  information  bases  and  tools,  and  aids  to  facilitate 
location  and  movement  of  information. 

Infrastructure  Services.  See  Core  Networking  Services. 

Intelligent  Agent.  See  Intermediary. 

Interface  Definition  Language.  A technique  for  specifying  the  interface  to  a service, 
used  by  an  intermediary  service,  so  that  services  using  heterogeneous  protocols  and 
interfacing  methods  can  be  used  together.  The  Interface  Definition  Language,  or  IDL, 
allows  resolution  of  differences  in  data  representation  and  service  request  methods.  The 
service  provider  defines,  through  an  application  programming  interface  (API)  or  similar 
specification,  the  semantics  and  pragmatics  for  data  and  functions  available  through  the 
interface.  An  API  may  be  unique  to  a service  implementation,  may  be  used  by  several 
implementations  sharing  a common  specification,  or  may  be  standardized.  Simple 
intermediaries  can  broker  services  on  the  basis  of  IDL  alone.  Examples  are  the  Open 
Systems  Foundation  (OSF)  Distributed  Computing  Environment  (DCE)  and  the  Object 
Management  Group  (OMG)  Common  Request  Broker  Architecture  (CORBA).  More 
sophisticated  intermediaries  need  higher-level  knowledge  of  interfaces  obtained  from 
API’s. 
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Intermediary.  A service  that  provides  functions  by  which  to  interconnect,  adapt,  and 
facilitate  services  offered  by  other  parties.  Common  forms  of  intermediaries  include  the 
following: 

Agent.  An  agent  acts  on  behalf  of  one  of  the  interacting  parties.  The  party  the 
agent  represents  is  legally  responsible  for  actions  of  the  agent.  An  agency 
agreement  generally  provides  for  a continuing  relationship  that  extends  longer  than 
any  one  transaction  handled  by  the  agent.  Note  that  a service  user  may  have  an 
agent,  and  the  service  provider  may  have  an  agent  as  well.  In  such  a case,  a 
mediator,  as  described  below,  may  be  necessary  to  conclude  a contract.  An 
“intelligent  agent”  is  an  automated  process  that  operates  on  behalf  of  a user  or 
service  provider,  frequently  for  another  intermediary  service  offered  by  a broker  or 
trader,  according  to  rules  established  upon  its  invocation.  Only  infrequent  human 
interaction  is  needed  to  control  the  process  subsequently.  An  intelhgent  agent  is 
sometimes  referred  to  as  a “daemon.”  It  is  capable  of  flexible,  robust  interaction 
with  its  environment  in  goal-directed  behavior. 

Broker.  The  function  of  a broker  rehes  upon  the  definition  of  specific  roles  for 
two  other  parties  involved:  a client  who  initiates  a request  and  a target  who 
provides  service  in  response  to  a request.  The  client  finds  a service 
implementation  for  honoring  the  request,  prepares  the  service  interface  to  receive 
the  request,  and  communicates  the  data  making  up  the  request.  The  broker  is 
responsible  only  for  bringing  the  parties  together,  has  no  legal  responsibility  for 
satisfactory  completion  of  the  contract  between  the  client  and  service  provider,  but 
may  receive  compensation  from  either  or  both  parties  for  services  rendered.  A 
broker’s  obligation  usually  extends  only  to  the  transaction  at  hand;  the  broker  need 
not  have  a continuing  responsibility  to  either  party. 

Mediator.  A mediator  is  an  intermediary  capable  of  negotiating  aspects  of  the 
service  to  be  provided  (e.g.,  quality,  delivery  time,  cost)  impartially  to  meet  goals 
of  both  a service  requester  and  a service  provider.  The  mediation  function  will 
often  follow  broker,  trader,  or  agent  functions. 

Trader.  A trader  acquires  services  from  one  or  more  providers  for  “resale”  to  a 
client.  The  trader  insulates  the  client  and  service  provider  from  having  to  conduct 
business  directly  with  one  another.  The  trader  is  responsible  to  the  chent 
requesting  the  service  for  all  aspects  of  the  service. 

Key  Enabling  Services.  A broad  set  of  services  that,  taken  together,  provide 
significantly  more  capabihty  over  what  is  currently  available  toward  reahzing  the  Nil 
national  challenge  applications  (education,  manufacturing,  health  care,  etc.).  An  example 
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is  interpersonal  communications,  which  ranges  from  person-to-person  telephone  calls  to 
“virtual”  enterprises  wherein  groups  of  users  collaborate  using  multimedia  information  in  a 
what-you-see-is-what-I-see  conference. 

Local  Information  Environment.  The  services,  interfaces,  formats  and  protocols 
supplied  by  an  SPC  to  the  customer  as  a business  offering.  That  is,  how  the  information 
appliance  access  point  is  implemented,  including  any  value-added  services  the  SPC  offers. 

Mediator.  See  Intermediary. 

Repository.  A collection  of  information  that  serves  to  identify,  find,  and  characterize 
services,  resources,  and  other  information  necessary  or  useful  in  the  access  to  services  and 
operation  of  the  Nil.  Examples  are  directories,  catalogs,  and  indexes. 

Service.  A persistent  function  or  activity  (i.e.,  one  intended  for  reuse)  offered  as  a 
capabihty  for  satisfying,  in  part,  the  goals  of  a user  of  an  application.  A service  is  often 
developed  with  the  intent  of  collecting  revenue  for  its  usage  according  to  pre-established 
fee  schedules.  Services  are  intended  to  serve  more  than  one  user.  A technology-based 
service  is  a capabihty  that  can  be  implemented  by  equipage,  processes,  and  procedures 
through  a predefined,  minimum  set  of  interfaces  that  specify  outcomes  of  service  requests 
(rather  than  the  behaviors  of  the  service  provider).  These  interfaces  are  either  for  direct 
service  use  or  for  management  of  the  services.  Non-technology-based  services  are  not 
within  the  scope  of  this  document. 

Seamless.  Describes  a networking  protocol  intended  to  provide  passage  of  information 
across  diverse  bitways  transparently;  analogous  to,  but  with  significantly  more 
functionality  than,  the  Internet  Protocol  or  the  Open  Systems  Interconnection  (OSI) 
Connectionless  Network  Protocol  (CLNP). 

Service  Environment.  A collection  of  functions  and  services  directed  at  specific  kinds  of 
usage  and  applications.  In  particular,  a service  environment  consists  of  service  definitions, 
service  interfaces,  core  networking  services  required,  and  management  and  billing  functions, 
plus  intermediaries,  tools,  and  repositories  for  the  management  of  these  components. 

Service  Interface  Components.  Hardware  or  software  associated  with  an  information 
apphance  that  is  used  to  interact  with  the  information  appliance  access  point  to  obtain 
services.  Examples  are  a set-top  box  for  cable  television;  accessing  software  for  computer 
services  (CompuServe,™  Prodigy,^^  America  Online,™  etc.);  or  a terminal  adapter  for 
narrowband  ISDN. 
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Service  Provider  to  the  Customer  (SPC).  The  SPC  is  the  implementor  of  an  information 
appliance  access  point.  An  information  appliance  access  point  could  be  provided  by  a cable 
television  company,  a telephone  local  exchange  carrier,  a global  satellite  network  company,  a 
cellular  or  mobile  telephone  conpany,  a commercial  data  network  (e.g.,  ACCUNet),  a 
telephone  interexchange  carrier,  or  a noncommercial  organization  (e.g.,  governments, 
Internet).  When  using  a mobile  information  appliance,  more  than  one  of  the  access  point 
providers  could  gain  access  for  the  user;  i.e.,  access  need  not  be  constrained  to  a single 
provider.  An  important  issue  is  the  commonality  of  characteristics  of  the  information  appliance 
and  the  access  characteristics  the  access  provider  offers  at  the  particular  access  point.  See  also 
Application  Access  Point. 

Trader.  See  Intermediary. 

Value-added  Service.  A service  available  to  users,  usually  at  extra  charge,  as  a 
supplementary  capability  to  a conventional  or  standard  offering  of  services. 
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B.  ELEMENTS  OF  THE  APPLICATION  ENVIRONMENT 


To  provide  a more  complete  picture  of  the  Nil  Services  Framework,  it  is  necessary  to 
consider  the  applications  environment,  shown  at  the  top  of  the  Nil  Services  Model  (Figure 
2.4).  The  interactions  between  application  systems  and  the  enabhng  services  provided  by 
the  Nil,  as  well  as  the  Nil  services  themselves,  will  be  based  on  distributed  systems 
technology,  coupled  with  object-oriented  computing. 


B.l  DISTRIBUTED  PROCESSING 

The  Nil  win  use  distributed  systems  technology  to  control  processing  and 
communications.  Distributed  systems  are  characterized  by  software  components  and 
databases  that  are  physically  distributed,  and  by  heterogeneous  interconnection 
characteristics  and  diverse  mechanisms  for  cooperation.  Nil  applications  either  will  be 
parts  of  larger  systems  that  engage  in  distributed  computing  or  will  themselves  be  using 
distributed  capabihties.  Each  component  of  a distributed  system  will  require  support  from 
underlying  Nil  services  to  communicate  with  other  components,  to  exchange  data,  and  to 
coordinate  distributed  processing  tasks.  The  required  services  include,  at  a minimum,  aU 
core  communications  services.  They  may  also  include  core  management  services  and 
supporting  services. 


B.2  MODELS  OF  DISTRIBUTION 

Distributed  processing  within  the  Nil  will  require  coherent  models  of  distributed 
computing.  Many  such  models  have  been  created  in  the  research  community  over  the  last 
decade,  some  of  which  have  been  implemented  in  commercial  products.  Two  prominent 
examples  are  distributed  database  management  and  the  client-server  computing  model. 
These  models,  together  with  other  models  of  distributed  computing  under  development, 
will  provide  the  basis  for  Nil  applications.  Key  enabling  services  used  to  develop 
application  systems,  such  as  collaboration,  simulation,  and  digital  hbraries,  will  employ 
models  of  distribution.  Use  of  underlying  models  of  distribution  will  also  provide  part  of  a 
framework  in  which  Nil  services  can  be  linked  to  enable  development  of  applications. 
These  underlying  models  of  distribution  will  need  to  be  defined,  standardized,  and  tested 
to  ensure  that  application  systems  using  them  will  be  interoperable.  Suppliers  of  Nil 
services  will  then  be  able  to  develop  specific  services  that  can  be  integrated  within 
appropriate  models  of  distribution. 
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B.3  REALIZING  OF  MODELS  OF  DISTRIBUTION  THROUGH 
FRAMEWORKS 

There  are  two  areas  of  focus  for  using  models  of  distribution  in  the  development  of 
application  systems  for  the  Nil:  (1)  achieving  interoperability  between  dissimilar  systems, 
and  (2)  using  software  development  tools  that  are  based  on  models  of  distributed 
processing.  One  important  facet  of  achieving  interoperability  is  satisfying  constraints  on 
the  use  of  a particular  service.  These  constraints  are  seen  in  the  service  interface  by  the 
user  of  the  service  (where  the  user  can  be  a person,  application  system,  or  other  service). 
For  application  developers,  the  attempt  to  integrate  multiple  services  into  an  application, 
where  each  service  imposes  different  constraints  that  may  be  incompatible,  can  present 
difficulties.  To  aid  the  application  developer,  reusable  frameworks  based  on  particular 
models  of  distribution  will  be  provided.  Frameworks  are  reusable  templates  that  can  be 
used  as  skeletons  from  which  applications  can  be  built.  Frameworks  provide  a means  to 
resolve  potentially  incompatible  constraints.  Applications  whl  be  constructed  by  adapting 
and  customizing  frameworks.  For  service  interfaces  that  are  not  sufficiently  constrained  to 
achieve  interoperability,  frameworks  may  add  necessary  constraints.  To  help  manage  the 
complexity  for  the  developer,  software  development  support  tools  and  environments  will 
be  enhanced  to  support  such  frameworks. 

A popular  example  of  a framework  can  be  found  in  typical  graphical  user  interface  (GUI) 
programming  environments.  Such  environments  provide  window  definition  primitives, 
window  management  capabilities,  window  manipulation  capabilities,  and  other  features. 
GUI  frameworks  may  also  contain  buttons,  edit  boxes,  and  hsts  that  can  be  modttied  and 
incorporated  into  applications.  Specific  software  tools  that  support  these  capabilities  can 
be  integrated  into  a GUI  framework  and  used  to  develop,  deploy,  and  test  application 
systems.  At  present,  GUI  frameworks  are  being  developed  which  incorporate  models  of 
distribution  that  integrate  distributed  services  for  presentation  on  a particular  workstation. 
Examples  of  this  are  the  X-Windows  system  and  OpenDoc,  described  below.  Not  only 
are  frameworks  such  as  these  needed  to  support  models  of  distribution,  but  it  must  be 
possible  to  link  multiple  such  frameworks  to  create  a single  application. 


B.4  THE  ROLE  OF  OBJECT  COMPUTING 

A current  trend  in  software  development  is  to  develop  application  systems  that  are  based 
on  object  computing,  also  referred  to  as  object-oriented  technology,  or  object  orientation. 
For  the  purposes  of  this  discussion,  objects  are  computational  entities  in  which  data  and 
procedures  are  bundled  together  internally  and  hidden  from  external  access  and  view. 
Communication  with  objects  is  accomplished  by  invoking  specific  object  functions  using  a 
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well-specified,  public  interface.  In  the  object  approach,  abstract  data  types  or  classes  are 
used  to  define  object  types  having  specific  functions  and  behaviors  that  can  be  invoked 
through  defined  public  interfaces.  In  a distributed  computing  environment,  all 
communicating  systems  are  defined  as  instances  of  particular  object  classes;  aU  such 
objects  communicate  using  public  interfaces  developed  for  objects  of  a particular  class. 
The  use  of  the  object  computing  concepts  to  provide  the  conceptual  underpinnings  for 
communications  in  a distributed  environment  has  given  rise  to  the  vision  of  distributed 
object  computing  in  the  NIL 

In  a distributed  object  computing  environment  for  the  Nil,  application  systems  would 
comprise  objects,  having  public  interfaces  and  private  implementations  hidden  from 
external  view.  Uniform  service  interfaces  would  be  established  to  allow  communications 
between  objects  belonging  to  defined  object  classes,  leading  to  the  development  of  a 
distributed  processing  infrastructure  for  the  NIL  Object  computing  principles  could  be 
used  to  re-architect  existing  legacy  systems  for  inclusion  in  the  Nil:  filesystems  become 
object  repositories,  databases  become  object  databases,  programming  languages  add 
support  for  defining  and  communicating  with  objects,  and  networks  and  distributed 
systems  become  distributed  object  systems.  This  does  not  imply  that  object  technology 
will  necessarily  replace  the  existing  technology.  Instead,  the  object  technology  will  be 
used  to  enhance  and  adapt  current  systems  developed  with  pre-object  technologies  to 
allow  them  to  operate  in  an  object  computing  environment. 

The  object  model  of  computing  is  general;  many  variants  of  the  basic  model  have  been 
conceived  to  provide  underpinnings  for  programming  languages  and  database  systems,  as 
well  as  distributed  communications.  Although  arising  from  the  same  basic  vision  of 
computing,  systems  developed  using  different  versions  of  the  object  model  have  proven  to 
be  incompatible. 


B.5  STANDARDS  FOR  DISTRIBUTED  OBJECT  COMPUTING 

Distributed  object  computing  provides  a basis  for  developing  Nil  services  that  in  turn  can 
be  used  to  develop  applications.  The  enabhng  of  distributed  object  computing  will  require 
the  development  of  standards  based  on  a common  model  of  object  computing  that  allows 
diverse  systems  to  interoperate.  One  example  of  such  an  effort  is  provided  by  the  Object 
Management  Group  (OMG).  OMG  was  chosen  as  an  example  of  an  effort  to  foster  the 
development  of  standards  because  it  offers  a relatively  weU-defmed  structure  for 
developing  applications  based  on  object  computing.  Other  possible  examples,  such  as 
Open  Distributed  Processing  (ODP)  effort  [7],  also  could  be  discussed  but  were  omitted 
due  to  time  and  space  constraints.  OMG  was  organized  to  foster  adoption  of  object 
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technology  through  the  development  of  appropriate  standards  to  enable  distributed 
computing.  The  standards  developed  by  OMG  are  based  on  a common  object  model. 
These  standards  are  intended  to  provide  the  ability  to  specify  an  infrastructure  that 
supports  definition  and  interoperation  of  distributed  objects.  This  infrastructure  then 
provides  a basis  for  the  development  of  services  and  application  systems.  In  the  case  of 
OMG,  a reference  model  has  been  defined,  called  the  Object  Management  Architecture  [8- 
10].  This  architecture  has  four  major  parts: 

• Object  Services  provide  basic  functions  for  defining,  implementing,  and  using 
objects  and  object  types.  These  services  include  persistence,  security,  concurrency 
control,  data  interchange,  and  others. 

• The  Object  Request  Broker  (ORB)  enables  an  object  to  be  activated  (moved 
from  storage  into  memory  and  started),  and  provides  the  ability  for  objects  to  send 
and  receive  messages  that  invoke  functions  performed  by  the  object.  The  ORB  is 
based  on  a client-server  model  in  which  a client  object  conceptually  requests 
services  from  a server  object  by  sending  a message  that  invokes  a function  on  the 
server  object.  This  client-server  model  for  requesting  services  provided  by  an 
object  has  implications  for  the  Nil,  as  is  discussed  below. 

• Common  Facilities  are  special  services  that  provide  general-purpose  capabihties 
useful  for  many  applications,  such  as  browsers,  reusable  interfaces,  electronic  mail, 
and  others. 

• Application  Objects  are  defined  by  OMG  as  objects  that  are  part  of  end-user 
applications.  The  role  of  application  objects  in  the  Nil  is  discussed  below. 

To  support  application  development,  an  infrastructure  based  on  an  architecture  such  as  the 
one  described  here  will  have  to  be  complemented  by  other  components,  such  as  interface 
definition  languages  and  repositories.  Interface  definition  languages,  such  as  the  IDL 
developed  by  OMG,  are  used  to  define  public  interfaces  to  objects.  Interfaces  defined 
using  such  a language  are  generic;  they  are  language-independent  specifications  that  can 
be  translated  into  code  used  to  build  specific  implementations.  Repositories  store 
interface  definitions,  developed  using  interface  definition  languages,  together  with  object 
implementations.  These  repositories  can  be  accessed  by  developers  who  retrieve  and 
reuse  appropriate  items  to  develop  their  applications. 

The  OMG  view  of  distributed  object  technology  is  language-neutral,  location-transparent, 
operating  system-independent,  and  machine-independent.  At  present,  individual 
corporations  are  beginning  to  use  the  Object  Management  Architecture  to  create 
competitive  distributed  object  management  systems  (DOMS).  Using  OMG  specifications 


B-4 


as  a basis,  DOMS  offer  solutions  for  integrating  legacy  applications  and  databases  in 
heterogeneous  distributed  systems.  To  do  this,  DOMS  provide  an  object  management 
system  capabihty  that  is  layered  on  top  of  the  legacy  systems.  DOMS  also  provide  a 
technology  substrate  on  which  distributed  applications  can  be  constructed. 


B.6  DEFINING  OBJECTS  THAT  PROVIDE  NH  SERVICES 

The  example  of  the  OMG  view  of  object  computing  aligns  well  with  the  vision  of  an 
infrastructure  needed  to  provide  Nil  services.  In  this  view,  the  Object  Management 
Architecture  or  an  equivalent  would  provide  a basis  for  defining  objects  that  can  be 
invoked  to  provide  Nil  services  using  public  interfaces.  In  viewing  objects  as  services,  it 
is  necessary  to  focus  on  interfaces.  In  the  object  model  of  computing,  interfaces  are  the 
intersection  points  between  objects.  An  interface  specifies  the  following: 

• The  syntactic  structure  (or  signature  of  the  operations) 

• Constraints  apphcable  to  these  operations,  such  as  timing,  operation  sequencing, 
and  data  integrity  constraints 

• A description  of  the  function  of  the  object 

An  object  may  have  many  interfaces.  These  interfaces  may  differ  with  respect  to  the 
amount  of  access  that  can  be  offered  and  the  customization  for  particular  environments. 


B.7  SERVICE  PROVIDERS  TO  THE  CUSTOMER  AND  DISTRIBUTED 
OBJECT  TECHNOLOGY 

Objects  and  the  supporting  object  technology  create  a logical  infrastructure  for  providing 
access  to  Nil  services  that  can  be  fit  into  the  physical  environment  defined  by  the  service 
provider  to  the  customer  (SPC)  and  other  service  providers.  An  ORB  defines  a logical 
domain  in  which  objects,  and  therefore  services,  reside.  A service  is  offered  via  its  local 
ORB  by  being  registered  in  the  server  registry  associated  with  the  ORB.  ORBs  can  be 
linked  to  make  services  from  other  domains  available.  Within  a local  computing 
environment,  ORBs  may  be  assigned  per  user,  per  computing  platform,  etc. 

There  are  options  for  configuring  ORBs  in  both  the  SPC  and  customer  environments. 
Within  the  SPC  environment,  the  SPC  would  provide  an  ORB  that  customers  could  use. 
A choice  would  be  provided  of  having  one  ORB  per  customer  connection  or  having  one 
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ORB  service  for  all  SPC  customers.  All  Nil  information  services  would  be  delivered  to 
the  customer  through  that  ORB(s).  The  ORB  would  shield  the  customer  from  the 
location  of  services  and  the  complexities  of  the  rest  of  the  Nil. 

Within  the  customer  environment,  configurations  can  be  divided  into  two  classifications. 
First  are  customers  that  use  the  SPC-provided  ORB  as  their  primary  ORB;  this  would 
include  low  computing-power  and  single-use  devices.  Second  are  customers  that  supply 
their  own  ORB  for  local  object/service  management;  this  group  includes,  for  example, 
organizations  that  support  in-house  local  area  networks  (LANs)  or  private  branch 
exchanges  (PBXs)  or  individuals  with  workstations.  This  distribution  of  ORBs  provides 
the  underpinning  for  two  approaches  for  delivering  software:  objects  as  commodities  (buy 
a copy  for  local  use)  and  objects  as  services  on  the  network  (remote  access  to  a server). 
In  both  customer  environments,  these  objects  become  part  of  the  infrastructure. 
Applications,  both  commercial  and  in-house,  will  grow  to  depend  on  these 
objects/services.  Issues  of  quality  control,  longevity,  rehabihty,  and  Habihty  wiU  become 
paramount.  Even  though  the  technology  can  be  distributed  throughout  the  marketplace, 
responsibility  to  a customer  must  come  through  a single  or  a few  providers. 


B.8  ISSUES  IN  MANAGING  DISTRIBUTED  COMPUTING  IN  THE  Nil 

This  section  addresses  several  important  aspects  of  the  management  and  organization  of 
distributed  computing  in  the  Nil,  including  federated  forms  of  control,  the  use  of  traders 
to  hnk  objects  providing  services  to  users  of  those  services,  the  integration  of  Nil 
information  services  with  multimedia,  and  presentation  of  an  integrated  view  of  services 
on  a graphical  user  interface. 


B.8.1  Federated  Control 

The  Nil  win  comprise  a diverse  set  of  components.  No  one  single  organization  can 
manage  the  entire  NIL  Instead,  a federated  approach  to  management  and  control  wiU  be 
required.  A federated  approach  to  naming  will  be  required  to  ensure  that  consistent  names 
are  used  for  the  diversity  of  Nil  components.  Interface  types  wUl  be  created  by  many 
organizations  under  many  authorities  for  national  and  local  markets  and  private  use.  Once 
created,  an  interface  may  have  a long  life  and  be  referred  to  by  many  other  elements  of  the 
environment.  Identifiers  for  individual  objects  wUl  be  simUar  characteristics.  Federated 
naming  with  local  control  over  local  functions  is  necessary  to  manage  the  diversity.  A 
root  authority  for  naming  will  have  to  be  established  for  the  entire  NH. 
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Experience  with  the  first  generation  of  search  and  discovery  tools  available  on  the 
Internet  [11]  has  demonstrated  the  congestion  problems  that  occur  when  frequently 
referenced  information  bases  are  not  replicated.  Both  interface  repositories  and 
implementation  repositories  will  require  replication. 

As  a commercial  enterprise  beyond  the  LAN,  the  facilities  providing  the  commercial 
brokers,  repositories,  and  objects  (whose  interfaces  provide  services)  will  require 
management,  maintenance,  and  day-to-day  support.  Realistic  management  architectures, 
interfaces,  and  facihties  must  exist  to  support  the  day-to-day  operation  of  the  NIL  Some 
early  architecture  efforts  in  this  area  are  described  in  the  Bellcore  INA  project  [12-15]. 
The  framework  defined  by  this  project  is  synergistic  with  the  OMG  efforts. 


B.8.2  Traders 

Trader  objects/services  [16]  support  the  Unking  of  clients  and  servers  in  a distributed 
system  in  which  multiple  service  offerings  are  available  to  satisfy  the  service  needs  of  a 
cUent.  Specifically: 

• A trader  accepts  service  offers  from  service  providers. 

• A trader  accepts  service  requests  from  clients  of  services. 

• A service  request  is  expressed  as  service  requirements  by  the  client. 

A trader  searches  its  service  offer  database  to  match  the  client  request.  The  trader  can 
select  a single  service  offer  that  matches  the  request  or  can  select  aU  offers  that  match. 
The  selected  offers  are  returned  to  the  client. 


B.8.3  Multimedia 

The  OMG  architecture  and  components  offer  a basis  for  the  discussion  of  information 
services  within  the  NIL  But  a large  part  of  the  Nil  discussion  centers  on  the  integration  of 
information  services  with  audio  and  video  services.  A separate  organization,  the 
Interactive  Multimedia  Association,  has  published  a Multimedia  System  Services  Request 
for  Technology.  One  submission  in  response  to  the  request  for  technology  from  Hewlett- 
Packard,  International  Business  Machines,  SunSoft,  and  others,  offers  insight  into  the 
integration  of  multimedia  into  the  OMG  architecture  [17]. 

Some  key  concepts  defined  are  as  follows: 
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• Stream.  A flow  of  media  data  through  a device  or  across  a connection. 

• Virtual  Device.  Defines  issues  of  resource  management,  stream  position  control, 
device  abstraction,  and  media  format  abstraction. 

• Format.  Defines  the  format  hierarchy,  which  includes  various  forms  of  digital 
audio  and  digital  video. 

• Virtual  Connection.  An  abstract  view  of  media  transport  between  virtual 
devices. 

• Core  Quality  of  Service  Characteristics.  Characteristics  for  audio  and  video 
streams  are  defined. 

Objects  are  identified  for  key  control  points  and  control  parameters  in  the  media  data  flow. 
These  cooperating  objects  interact  to  provide  a flow  of  control  information  separate  from 
the  media  data  flow.  This  framework  is  therefore  analogous  to  the  separate  signaling  and 
bearer  channels  that  exist  in  telephony. 

The  Multimedia  System  Services  encompass  the  following  characteristics: 

• Provision  of  an  abstract  interface  for  a medial  processing  node,  extensible  to 
support  abstractions  of  real  media  processing  hardware  or  software 

• Provision  of  an  abstract  interface  for  the  data  flow  path  or  the  connection  between 
media  processing  nodes,  encapsulating  low-level  connection  and  transport 
semantics 

• Grouping  of  multiple  processing  nodes  and  connections  into  a single  unit  for 
purposes  of  resource  reservation  and  stream  control 

• Provision  of  a media  dataflow  abstraction,  with  support  for  a variety  of  position, 
time,  and/or  synchronization  capabilities 

• Separation  of  the  media  format  abstractions  from  the  dataflow  abstraction 

• Synchronous  exceptions  and  asynchronous  events;  application  visible 
characterization  of  object  capabilities 

• Registration  of  objects  in  a distributed  environment  by  location  and  capabilities 

• Retrieval  of  objects  in  a distributed  environment  by  location  and  constraints 
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Definition  of  a Media  Stream  Protocol  to  support  media-independent  transport  and 
synchronization 

Use  of  OMG  CORE  A technology  as  the  basis  for  supporting  distributed  objects 


B.8.4  OpenDoc 

The  object  model  of  computing,  as  evidenced  in  the  ORB,  facilitates  integration  of 
distributed  Nil  services.  A different  set  of  integration  issues  must  to  be  addressed  to 
coordinate  the  presentation  of  services  to  a user  on  the  information  appliance.  This 
obviously  apphes  only  to  workstation  class  appliances,  but  these  reflect  a very  important 
market  segment. 

Workstations  imply  the  use  of  both  local  and  remote  software  objects.  Distant 
objects/services  v^l  be  accessed  via  locally  accessible  brokers.  Local  services  (local 
implying  on  the  workstation)  could  be  integrated  via  a broker.  But  brokers  do  not  offer  or 
control  access  to  the  user  interface,  nor  do  they  take  into  account  the  types  of  integration 
necessary  for  the  user  interface:  sharing  of  keyboard,  display  real  estate,  audio/video 
accessories  etc.  Technology  focused  on  the  integration  and  presentation  of  services  on  the 
apphance  is  therefore  necessary.  As  a contribution  to  that  niche,  the  OpenDoc  [18] 
architecture,  has  been  created  by  a joint  effort  on  the  part  of  Apple,  WordPerfect,  Novell, 
Borland,  and  IBM.  OpenDoc  targets  the  integration  of  services/software  components  for 
the  appliance. 

OpenDoc  defines  a compound  document  architecture.  This  is  an  open  architecture  based 
on  a document  metaphor  for  organizing  graphical  presentation  that  is  designed  to  integrate 
software  elements  and  enable  sharing  across  multiple  vendors  and  computer  platforms. 
This  architecture  offers  an  object-based  framework  based  on  OMG  CORBA  object 
technology,  specifically  IBM’s  System  Object  Manager  (SOM).  Integration  with 
OpenDoc  on  the  appliance  provides  uniformity  of  the  user  interface  and  allows  software  to 
be  structured  into  independent  components. 

There  are  two  possible  futures  for  this  kind  of  technology.  OpenDoc,  or  OpenDoc-like 
technology  that  offers  desktop/appliance  integration,  will  become  part  of  the  infrastructure 
since  it  affects  the  presentation  of  services,  and  therefore  services  will  be  constructed  with 
such  technology  in  mind.  The  other  possibility  is  that  the  effects  of  this  technology  area 
will  be  restricted  to  the  appliance,  and  control  over  the  appliance  will  remain  with  the 
appliance  vendor. 
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B.9  THE  VIEW  FROM  THE  APPLICATIONS  ENVIRONMENT 


Application  development  in  this  environment  will  be  heavily  influenced  by  the  support 
technology  in  the  form  of  Nil  services  that  will  be  available.  Some  key  elements  visible  to 
the  application  developer  will  be  the  following: 

• Large  bodies  of  reusable  code  available  in  object/service  implementation 
repositories.  The  source  code  wiU  not  be  available.  Interface  definitions, 
functional  definitions,  operational  constraints,  attributes,  and  dependencies 
available  from  interface  (and  possibly  design)  repositories  will  be  relied  on  for 
selection  of  reusable  elements. 

• More  effort  wiQ  be  expended  in  searching  for  and  examining  components  than 
creating  new  components.  Search  tools  will  have  paramount  importance. 

• Distributed  frameworks  wiQ  offer  basic  integration  of  components  targeted  at 
typical  tasks  and  problems.  Selecting  the  proper  framework  for  an  application  will 
be  a key  decision.  CompatibUity  between  frameworks  and  component 
objects/services  will  be  a big  concern  for  application  developers. 

• The  code  written  by  an  application  developer  will  direct  the  components. 

Key  issues  for  the  application  developer  wbl  be  findabbity  and  rebabibty  of  components 
and  frameworks  to  support  the  application. 
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APPENDIX  C 


DATA  AND  KNOWLEDGE  MANAGEMENT 

SERVICES 


C.  DATA  AND  KNOWLEDGE  MANAGEMENT  SERVICES 


This  appendix  represents  an  initial  attempt  to  examine  data  and  knowledge  technologies 
and  highlight  the  changes  needed  to  apply  database  management  system  techniques  to  the 
NIL 

There  is  currently  a mental  association  in  many  people’s  minds  between  the  term 
“database”  and  the  commonly  used  database  management  system  (DBMS)  software 
products  which  are  produced  and  sold  by  major  DBMS  kernel  manufacturers.  This 
association  is  valid,  but  it  is  also  overly -restrictive.  A database  is  any  collection  of  data 
with  a coherent  structure  that  can  be  manipulated  in  some  well-understood  way  using 
some  primitive  set  of  data-processing  operations.  Systems  that  manage  routing  tables  for 
computer  networks,  electronic  mail  aliases,  and  even  the  information  in  electronic  personal 
planners  are  also  DBMSs,  though  they  are  frequently  overlooked. 

Data  and  knowledge  management  capabihties  wiU  be  a critical  component  of  the 
infrastructure  of  the  NIL  It  can  be  anticipated  that  specific  DBMS  capabihties,  such  as 
distributed  transaction  management  and  self-de scrip tion,  will  underlie  key  enabhng 
services  discussed  in  Section  3 as  well  as  other  services.  Nearly  aU  key  enabling  services 
and  many  supporting  services  wih  incorporate  some  form  of  data  and  knowledge 
management.  However,  it  is  stih  early,  and  concrete  relationships  cannot  be  defined  yet. 
As  efforts  to  advance  the  Nil  continue,  a better  understanding  will  be  obtained  of  (1)  how 
Nil  services  will  use  data  and  knowledge  management  capabihties  and  (2)  how  DBMS 
technology  will  need  to  evolve  to  meet  the  needs  of  the  Nil. 


C.l  THE  IMPORTANCE  OF  DATA  SELF-DESCRIPTION  IN  THE  Nil 

Database  management  systems  have  always  drawn  a clear  distinction  between  the 
description  of  a data  set  and  the  data  set  itself.  This  separation  between  meta-data  and 
data  has  proven  extremely  useful  as  it  allows  us  to  query  not  only  the  currently  stored 
information  but  also  the  structure  of  that  information.  In  the  Nil,  this  self-descriptive 
property  will  become  increasingly  more  critical.  With  the  move  to  multimedia  in  the  Nil 
there  whl  be  an  arbitrary  collection  of  text,  digitized  sound,  and  binary  images,  as  well  as 
new  data  classes  such  as  digital  encodings  of  tactile  information,  ah  stored  on  disk 
according  to  their  own  peculiar  characteristics.  How  whl  applications  programs  be  able  to 
sort  out  this  almost  random  jumble  of  bits  if  the  information  storehouse  cannot  clearly  and 
efficiently  describe  its  own  structure? 
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A parallel  notion  in  database  management  is  that  of  data  independence.  Most  DBMSs 
provide  two  levels  of  data  independence:  logical  and  physical.  New  information  will 
constantly  be  added  to  the  Nil  and  new  and  better  ways  to  manage  the  physical  layer 
where  the  data  is  stored  will  constantly  be  uncovered.  The  Nil,  then,  must  be  flexible 
enough  to  easily  extend  its  own  self-description  and  improve  its  retrieval  performance 
without  disturbing  the  current  set  of  users  and  programs  which  are  interfacing  with  it. 

Also  important  to  databases  are  the  notions  of  data  abstraction  and  mnemonic  naming. 
One  would  like  to  be  able  to  directly  request  access  to  War  and  Peace  instead  of  having  to 
issue  a large  number  of  lower-level  commands.  In  DBMS  environments  this  is  possible 
via  data  abstraction,  a process  that  hides  the  details  of  how  one  stores,  manipulates,  and 
retrieves  complex  structures  such  as  images,  sound  clips,  or  highly  formatted  documents, 
and  similarly  via  a notion  of  a system  catalog  that  hides  the  storage  location  of  every 
object  from  the  user,  allowing  him/her  to  access  that  data  directly,  by  using  its  mnemonic 
name.  Today  these  are  very  pleasant  features;  in  the  Nil  environment  they  will  be 
requirements  for  success. 

The  Nil  extension  of  these  notions  will  be  the  addition  of  a new  level  of  abstraction  which 
hides  the  mnemonic  names  of  all  objects  related  to  some  mental  concept  underneath  the 
name  of  that  concept.  This  feature  whl  provide  content-based  addressing.  An  Nil  user 
wlQ  be  able  to  ask  for  aU  information  content  on  “Tolstoy’s  Novels”  and  directly  retrieve 
War  and  Peace  as  well  as  Anna  Karenina. 

There  are  many  problems  to  be  solved  here.  First  is  a need  to  automatically  extract  the 
content  from  data  objects  of  all  types.  Second  is  a need  to  create  concepts  over  very  large 
sections  of  the  Nil.  There  may  be  hundreds  of  thousands  of  references  to  a concept  at 
tens  of  thousands  of  database  storehouses,  yet  each  of  those  relationships  must  be 
maintained. 


C.2  SUPPORT  FOR  MULTIPLE  VIEWS 

Views  take  into  account  the  fact  that  not  aU  users  want  the  same  presentation  of  data. 
This  disparity  among  users  will  only  be  exacerbated  in  the  context  of  the  Nil.  The 
database  systems  should  present  different  views  of  the  information  for  people  with 
different  levels  of  interest  in  the  details  of  a topic,  with  different  educational  levels,  with 
different  background  in  the  information  being  queried,  with  different  abhities  to  see  or 
hear  or  read,  with  different  security  clearances,  and  so  forth.  It  may  be  useful  to  recall  the 
past  tight-coupling  between  database  and  artificial  intelligence  (AI)  research.  Many  of 
these  information  screening  and  presentation  issues  may  be  better  solved  with  AI 


C-2 


techniques,  such  as  the  emerging  personal  electronic  agent  technologies,  than  with 
traditional  DBMS  select-project-join  approaches. 


C.3  THE  HUMAN  FACTOR  IN  THE  DBMS  EQUATION 

Another  change  that  the  Nil  will  force  on  the  DBMS  community  will  involve  the  people 
who  are  traditionally  involved  in  a database  project.  In  standard  usage,  there  is  a data 
administrator  (DA),  who  is  responsible  for  the  information  content  and  the  policy 
decisions  made  in  a data  environment.  Also,  there  is  a collection  of  database 
administrators  (DBA)  who  are  responsible  for  deploying  the  information  content  and 
enforcing  the  policy  decisions. 

Certainly,  in  the  context  of  the  Nil,  these  tasks  will  become  intractable  for  human  beings. 
Is  it  possible  for  a group  of  people,  regardless  of  their  number,  to  track  every  piece  of 
information  coming  into  every  application  running  on  the  Nil  without  introducing 
unnecessary  delays,  which  the  Nil  is  targeted  at  eliminating?  Can  human  beings  create 
and  adapt  new  information  policies,  or  revise  old  ones,  at  the  rate  that  such  changes  will 
be  requested  and  required?  In  the  opinion  of  many  professionals,  the  answer  to  both  of 
these  questions  is  no. 

In  the  Nil  there  must  be  automatic  means  for  acquiring  new  information,  modifying  the 
system’s  self-description.  Unking  the  new  information  to  current  concepts  or  creating  new 
ones,  developing  an  information  poUcy  for  how  this  information  can  be  used  and  by 
whom,  and  distributing  aU  of  these  data  and  meta-data  changes  throughout  the  Nil 
distributed  system. 

The  same  argument  appUes  to  systems  analysts  and  applications  developers,  the 
individuals  that  examine  information  content  and  user  needs  to  plan  the  development  of 
immediately  required,  new  applications  and  then  build  them.  In  the  Nil,  the  goal  is  to 
allow  aU  users  of  any  technical  competency  real-time  access  to  aU  currently  available 
information.^  This  impUes  that  waiting  extended  periods  of  time  for  new  applications  to 
enable  interaction  with  currently  available  but  inaccessible  information  is  not  reasonable. 
Fortunately,  planning  is  a developing  field  of  study  in  AI  and  automatic  code  generation 
for  databases  is  a well-understood  and  frequently  solvable  problem  since  databases  are 
self-describing.  The  indication,  then,  is  that  these  DBMS  jobs  can  and  must  be  automated 
as  well. 


' Pursuant  to  established  security  policies,  of  course. 
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There  is  another  major  class  of  database  technologists  that  should  be  mentioned  here  as 
well:  those  who  actually  develop  and  improve  the  DBMS  kernels,  interface  tools,  and 
utilities.  Clearly  the  Nil  wiU  require  a tremendous  growth  in  this  field  of  database  system 
and  database  interface  research.  As  the  Nil  grows  and  the  amount  of  information  stored 
scales  ever  upward,  DBMS  technologies  must  evolve  at  the  same  or  faster  rates  of  speed. 


C.4  TRADITIONAL  DATABASE  GOALS  IN  THE  CONTEXT  OF  THE  Nil 

The  Nil  wiU  also  require  evolution  in  the  methods  used  to  meet  standard  DBMS  goals 
such  as:  controlled  redundancy,  data  sharing,  restriction  of  access,  provision  for  multiple 
interfaces,  backup  and  recovery,  standards  enforcement,  and  retrieval  of  the  most  recent 
data  that  satisfies  the  request. 


C.4.1  Controlled  Redundancy  And  Data  Sharing 

In  the  Nil,  a major  problem  whl  be  acquiring  new  data  objects  at  some  site  and  then 
propagating  them  quickly  and  efficiently  to  aU  places  where  they  wiQ  be  replicated.  The 
new  networking  advancements  which  allow  for  dynamically  maintained  minimum  spanning 
trees  over  a link-state  routing  algorithm  network  will  be  invaluable  in  this  area.  Other 
problems  vdll  be  the  sheer  quantity  of  information  being  stored  and  transmitted,  as  weU  as 
the  frequent  fluctuations  in  user-access  patterns.  There  simply  will  be  too  many  load 
shifts,  being  created  too  quickly,  and  concerning  too  many  pieces  of  information  to  allow 
for  typical  DBMS  techniques  such  as  repHcating  data  objects  close  to  the  point(s)  where 
they  are  most  frequently  accessed.  What  will  be  required  is  a way  for  the  DBMSs  of  the 
Nil  to  dynamically  restructure  the  replication  and  allocation  schemata,  at  machine  speeds, 
as  the  number  of  requests  for  an  object  shifts. 

The  issue  here  is  the  classic  database  problem  of  how  to  afford  a high  degree  of  local 
autonomy  without  compromising  the  larger,  global  or  Nil  system,  objectives.  Every  Nil 
node  should  be  capable  of  acquiring  new  information,  altering  its  own  structure  for 
performance  or  data  content  reasons,  ensuring  its  own  recoverability,  protecting  its  own 
consistency,  auditing  its  own  performance,  and  scheduling  and  managing  its  own  uptime 
and  downtime.  That  sounds  easy  until  one  reahzes  that  the  Nil  global  system  also  has 
data  content,  structure,  recoverability,  performance,  and  operational  schedule 
requirements.  Couple  this  fact  with  the  distributed  optimization  proofs  which  demonstrate 
that  one  cannot  achieve  global  optimality  by  optimizing  the  local  components,  and  the 
difficulties  to  be  faced  become  evident.  These  problems  will  be  further  complicated,  of 
course,  by  the  software,  data,  and  meta-data  versioning  and  configuration  control  issues. 
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Not  only  is  it  necessary  to  resolve  the  competition  between  autonomous  versus  global 
system  goals  and  requirements,  but  also  the  Nil  must  ensure  that  these  solutions  are  not 
circumvented  by  incompatibility  between  distinct  versions  of  Nil  software  components. 
There  is,  of  course,  the  parallel  issue  on  the  data  side.  The  Nil  will  support  concurrent 
engineering  which  requires  multiple  versions  of  a product  schematic  to  exist  along  with 
the  capability  to  allow  multiple  users  to  modify  the  schematic  simultaneously. 


C.4.2  Restriction  Of  Access  And  Provision  Of  Multiple  Interfaces 

Another  classic  problem  for  DBMSs  is  trying  to  balance  the  need  for  flexibility  in 
interfaces  against  the  need  for  restricting  access  to  information  by  certain  users.  Going 
back  to  the  notion  that  not  aU  users  are  created  equal,  it  is  clear  that  the  Nil  should 
provide  the  abihty  for  users  to  access  the  Nil  using  graphical  user  interfaces,  natural 
language  interfaces,  forms-based  interfaces,  standard  query  language  interfaces,  braille 
interfaces,  and  so  forth.  The  problem,  then,  is  largely  one  of  security.  Since  it  is  desired 
that  access  to  the  Nil  be  granted  through  any  kind  of  interface,  how  is  this  to  be  made 
possible  without  having  to  pubhsh  too  much  information  about  the  internals  of  the  Nil 
databases,  information  which  increases  the  risk  of  a successful  malicious  attack  on  the  Nil 
system? 

The  answer,  at  present,  is  partially  solved  through  the  use  of  standards.  The  Remote  Data 
Access  (RDA)  standard  (ISO  9579)  is  a relational  database  command  language  which  can 
be  used  to  communicate  with  any  vendor’s  RDBMS  without  bypassing  the  security  and 
authorization  mechanism  by  connecting  as  a DBMS  application,  which  usually  affords 
special  privileges — or  worse  yet — by  accessing  the  physical  data  directly.  Standardized 
DBMS  query  languages  allow  for  any  kind  of  interface  software  to  get  the  data  in  some 
canonical  and  safe  way.  Then  the  interface  software  can  process  it  further  to  generate  the 
special  display  characteristics  required. 


C.4.3  Backup  And  Recovery 

The  Nil  now  contains  data  abstractions  known  as  concepts  which  hide  the  mnemonic 
names  of  the  underlying  constituent  elements,  and  this  information  must  always  be 
accessible  to  running  Nil  DBMSs.  Also,  the  Nil  databases  that  map  mnemonic  names 
ambiguously  to  the  addresses  of  Nil  databases  which  contain  the  information  must  always 
have  their  information  content  available  everywhere.  That  would  imply  that  maybe  the 
architecture  should  partition  the  Nil  nodes  into  three  classes:  one  set  being  information- 
server  databases,  another  being  concept-server  databases,  and  the  third  being  name-server 
databases.  That  would  permit  performing  the  needed  fragment  replications  so  that  the  Nil 
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could  always  attempt  to  recover  the  information  content  of  a lost  Nil  database  from 
running  peers.  Also,  it  should  be  possible  to  save  redundancy  of  effort  by  not  backing  up 
aU  of  the  data  objects  at  all  of  the  nodes.  Careful  attention  paid  to  the  minimum  spanning 
trees  generated  by  the  routing  algorithm  can  certainly  allow  us  to  propagate  backups 
through,  some  k,  uptree  neighbors.  This  means  that  instead  of  storing  all  of  this 
information  in  backup  storage  at  all  /:+!  nodes,  the  Nil  can  store  it  only  once  and  send  it 
up  the  network  subtree  to  the  other  k nodes  if  and  when  it  is  needed. 


C.4.4  Standards  For  Distributed  Database  Systems 

The  Nil  will  need  standards  as  no  distributed  database  system  ever  has  before.  The 
reasons  are  the  intuitive  ones  surrounding  the  interoperability  issue.  Users  must  be  able  to 
access  and  update  databases  controlled  by  heterogeneous  DBMSs.  Nil  standards  would 
also  establish  markets  for  conforming  products,  and  that  is  with  what  the  government  as 
well  as  commercial  developers  will  most  likely  be  concerned. 


C.5  Nil  QUERY  LANGUAGES 

What  requires  more  elaboration  is  not  so  much  the  description  of  the  query  interfaces  but 
the  properties  that  Nil  queries,  generated  by  any  interface,  should  exhibit.  The  search 
space  on  the  Nil  wiQ  be  so  incredibly  large  that  queries  must  be  forced  to  be  painfuUy 
specific  just  to  counter  the  combinatorial  explosion  of  legal  query  responses.  The  problem 
is  how  wUl  the  interface  know,  before  attempting  to  retrieve  a practically  intractable 
information  set,  that  this  set  is  indeed  practically  irretrievable.  A shift  in  emphasis  is 
required,  from  data  management  to  knowledge  management  (including  the  management  of 
knowledge  about  knowledge).  Perhaps  the  concept-server  notion  could  be  useful  here,  as 
concepts  could  be  arranged  in  hierarchies,  and  every  node  in  the  tree  could  contain  a count 
specifying  the  current  number  of  known  references. 

Query  interfaces  should  also  check  Nil  queries  for  logical  inconsistencies  such  as,  “Show 
me  aU  people  who  are  not  people,”  as  these  also  would  waste  valuable  Nil  resources 
performing  useless  operations.  In  fact,  it  should  be  possible  with  appropriate  standards  to 
allow  the  query  interface  software  to  optimize,  decompose,  compile,  and  distribute  sub- 
queries to  Nil  nodes  in  executable  format.  This  would  be  highly  desirable,  as  it  would 
save  the  Nil  information-servers  almost  all  of  the  overhead  of  query-processing. 
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C.6  DATABASE  UTILITIES 


The  standard  set  of  database  utilities  should  definitely  be  extended  and  fully  automated  for 
use  in  the  Nil.  The  loader  module  should  automatically  import  new  information  which  has 
been  legally  sent  to  an  Nil  storehouse.  The  system  monitor  should  automatically  adjust 
buffer  sizes,  transaction  context  areas,  the  block  counts  for  multiblock  reads,  the  number 
of  available  file  handles,  etc.,  to  keep  performance  tuned  under  changing  system  load.  The 
security  and  authorization  subsystem  should  automatically  approve  new  user  accesses  and 
select  appropriate  security  privileges  as  the  American  public  comes  online. 

On  the  side  of  new  utilities,  these  examples  come  to  mind.  There  will  need  to  be  a whole 
assortment  of  software  modules  to  deal  with  the  various  communications  and  data 
protocols.  The  Nil  will  need  software  subsystems  to  manage  and  access  the  concept  and 
mnemonic  name  servers.  Knowledge-based  utihty  software  will  be  required  to  analyze 
and  classify  aU  incoming  data  objects  of  every  type.  Specialized  backup  and  recovery 
utihties  will  most  likely  be  employed,  and  there  should  be  some  notion  of  a clerical-utility 
to  track  important  events  at  every  node,  so  that  this  information  can  later  be  rolled  up  to  a 
central  Nil  site  for  performance,  access,  failure,  and  other  types  of  auditing. 


C.7  CLASSIFICATION  OF  THE  NH  DBMS 

One  is  tempted  to  go  with  a heterogeneous  Nil  system  that  would  allow  every  data  object 
to  be  stored  in  a data  model  that  is  most  appropriate  at  the  cost  of  mapping  between  data 
models  during  the  concept  retrieval  process.  The  federated  database  paradigm  may  be 
used  here  as  weU,  in  a slightly  modified  form,  if  it  is  possible  to  develop  a way  to  carefully 
control  replication  so  that  most  queries  can  be  answered  locally,  as  opposed  to  having  to 
go  through  the  more  general  Nil  network.  Integration  and  translation  issues  are  clearly 
very  important. 


C.8  TRANSACTION  MANAGEMENT 

Transaction  management  on  the  Nil  will  become  very  much  a synchronization  problem  of 
the  most  difficult  type,  which  is  synchronizing  data  delivery  from  multiple  sources  to 
multiple  sinks.  Another  issue  is  availabihty  of  all  pieces  of  a concept.  Certainly  the  Nil 
should  not  start  sending  the  information  if  it  is  aware  that  network  loads  or  downed  nodes 
will  prohibit  it  from  completing  the  delivery  in  a timely  fashion. 
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Recall  as  well,  that  the  Nil  will  have  some  very  long  duration  transactions  running  within 
it.  For  instance,  in  concurrent  engineering  applications,  there  could  be  hundreds  of  people 
in  hundreds  of  different  locations  working  an  entire  day  on  a single  design.  There  will  be  a 
need  to  tune  transaction  managers  to  deal  with  these  longer  and  more  complex 
transactions  or  logical  operation  sequences. 


C.9  FILES  AND  INDEXES 

In  the  Nn  environment,  database  files  and  indexing  schemes  will  have  to  adopt  totally  new 
appearances.  The  Nil  now  contains  incredibly  large  collections  of  binary  data,  be  it  aural, 
visual,  or  tactile.  In  terms  of  indexing,  in  a multimedia  setting  the  Nil  will  need  to  move 
to  feature-based  indexing  systems  that  look  not  at  information  headers  and  labels  but 
inside  the  data,  scanning  its  content. 


C.IO  DATABASE  DESIGN 

Database  design  typically  progresses  from  the  entities  and  relationships  captured  in  an  ER 
or  EER  diagram,  through  the  implementation-level  primitives  of  the  chosen  data  model, 
down  to  the  files  and  records  of  the  physical  layer.  A critical  issue  is  always  the  quality  of 
the  design  being  created.  A good  design  will  enable  database  use  and  future  development 
work  on  top  of  the  system.  A poor  design  will  definitely  impede  future  progress. 

The  quality  of  a database  design  is  normally  established  by  comparing  the  intended  data 
interrelationships  to  the  exphcit  interrelationships  in  the  system  design.  This,  in  practice, 
means  that  aU  logical  functional  dependencies  (FDs)  which  exist  in  a data  set  should  each 
be  captured  in  a single  primitive.  This  rule  prevents  the  database  designer  from  forcing  the 
system  to  reconstruct  connections  or  paths  between  primitives  every  time  an  update  is 
effected  and  the  FDs  must  be  validated. 

The  logical  question,  then,  is  what  does  an  FD  look  like  in  the  Nil  environment?  In  a 
standard  DBMS  environment,  an  FD  looks  like  ssn  — > name  and  indicates  that  any  given 
ssn  value  functionally  determines  a name  value.  Certainly,  these  standard  FDs  will  stiU 
exist  in  the  Nil  context.  However,  there  will  also  be  new  extensions  of  these  FDs  to 
capture  content-based  information.  Examples  might  be  image  — > setting  or  song 
mood.  Good  designs  will  need  to  heed  these  new  twists  on  the  old  notion  of  FDs.  If  this 
is  ignored,  the  old  problems  of  unnecessary  NULL-space,  spurious  and  danghng  tuples, 
and  insertion,  deletion,  and  modification  anomalies  again  will  plague  the  Nil’s  DBMSs. 
These  FDs  and  the  design  process  that  uses  them  handle  the  problem  of  ambiguity  that 
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may  be  found  in  database  modifications.  For  example,  if  the  design  is  poor  and  employees 
are  stored  with  hnks  to  images  of  project-logos  and  images  of  work-locations,  then 
changing  the  project-logo  that  is  hnked  to  an  employee  leaves  one  guessing  what  should 
happen  to  the  attached  work-location  image.  If  the  work-location  is  the  location  of  the 
project  then  it  should  change.  If  the  work-location  is  the  location  of  the  employee’s 
primary  office  then  it  should  not. 

Another  database  design  notion,  that  of  view  integration,  will  also  need  adjustment  to  suit 
the  NIL  It  is  common  practice  to  take  a large  set  of  diverse  user  data  and  functionality 
requirements  and  then  stepwise  synthesize  them  into  a single  coherent  global  picture.  In 
the  Nil,  the  fuU  set  of  data  and  function  requirements  will  never  exist.  The  Nil’s 
requirements  will  forever  remain  a dynamic  property.  The  challenge,  then,  is  to  design 
dynamic  view-integration  techniques  that  allow  for  evolutionary  data  and  function  design. 
In  addition  to  the  aforementioned  automatic  loaders  and  application  writers,  there  will 
need  to  be  a notion  of  a global  design  watchdog  that  ensures  that  the  “goodness” 
properties  of  the  system  structure  are  not  unduly  eroded  by  the  processes  of  incremental 
change. 


C.ll  QUERY  PROCESSING  AND  OPTIMIZATION 

As  mentioned  in  Section  C.5,  the  more  query  processing  activities  that  local  query  sites 
can  do,  the  better  for  the  NIL  The  biggest  cost  in  Nil  query  processing,  however,  will 
probably  not  be  the  standard  ones  of  query  decomposition,  compilation,  and  reassembly. 
The  biggest  costs  in  Nil  query  processing  will  be  in  the  resource  location  and 
synchronization  processes.  There  will  be  a requirement  to  bind  concepts  to  mnemonic 
names  and  then  ambiguously  to  physical  site  addresses.  There  will  be  a need  to  actually 
select  one  site  address  from  the  list  of  many,  hopefully  based  on  performance  metrics,  for 
each  object.  Then  there  will  be  the  need  to  enforce  multipoint  to  multipoint 
synchronization  rules  between  aU  querying  sites  and  all  involved  information  sources. 
Also,  access  to  some  objects  may  require  some  small  electronic  payment  to  be  rendered. 


C.12  DATABASE  CONSTRAINTS 

Even  database  constraints  will  need  to  evolve  to  meet  the  Nil  challenge.  Many  of  the 
restrictions  that  had  previously  fallen  into  the  class  of  semantic  constraints  and  were 
largely  ignored  will  now  need  to  be  rigorously  enforced.  For  example,  requiring  that  the 
meaning  of  a picture  (i.e.,  the  objects  captured  in  the  image)  be  related  to  the  database 
representations  of  aU  of  those  pictured  objects  and  to  no  others  will  be  critical.  Enforcing 
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sequence  constraints  over  data  objects,  like  the  various  images  in  a slide  show,  will  be 
required. 

In  addition,  aU  of  the  standard  integrity  constraints  will  necessarily  require  broadening. 
How  is  the  uniqueness  constraint  defined  over  images?  For  example,  are  two  pictures  of 
the  same  thing  with  two  different  backdrops  the  same  or  different  key  values?  How  is 
entity  integrity  defined  over  music?  Is  a long  pause  for  a number  of  measures  considered 
to  be  a NULL  value?  How  is  referential  integrity  formally  specified  over  tactile 
information?  Is  a successful  reference  achieved  based  on  texture  or  weight  or  size? 

Perhaps  even  more  critically,  is  the  Nil  going  to  permit  integrity  rules  to  move  from  the 
world  of  hard  and  fast  rules  to  the  universe  of  fuzzy  logic?  In  the  Nil,  it  now  seems  to 
make  some  sense  to  have  varying  degrees  of  matches  between  objects  and  hence  varying 
degrees  of  conformance  to  integrity  constraints. 


C.13  NEW  DATA  ENTITffiS 

In  the  Nil  environment,  temporal  and  spatial  data  will  become  critical.  For  electronic 
commerce,  temporal  information  attached  to  orders,  bids,  and  contracts  will  be  of  eminent 
importance.  For  health  care,  spatial  orientation  of  distant  hospitals,  doctors,  and  organs 
ready  for  transplant  will  be  critical.  Certainly  these  topics  of  spatial  and  temporal 
databases  have  been  adequately  researched.  It  is  up  to  the  Nil  to  test  and  vahdate 
proposed  approaches. 
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APPENDIX  D 


INTERWORKING  OF  BITWAYS 
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D.  INTERWORKING  OF  BITWAYS 


D.l  CROSS-INDUSTRY  INTERCOMMUNICATIONS  PROFILE  TABLE 

A completed  version  of  the  cross-industry  profile  table  shown  in  Section  5 (Table  5-1)  will 
illustrate  how  specific  information  industry  suppliers  currently  interconnect  and  distribute 
information  across  their  boundaries.  It  should  be  noted  that  in  some  instances, 
information  flow  between  some  industries  will  be  based  on  speculation  or  on  ongoing 
research  activities.  The  table  will  provide  invaluable  “real-world”  feedback  into 
understanding  such  issues  as  the  following: 

• Defining  relevant  Nil  services  from  a practical  “ground-up”  perspective 

• Mapping  tangible  interface  technology  with  services 

• Applying  the  services  to  various  Nll-specific  domains  and  challenges 

Gaps  in  the  entries,  or  hghtly  addressed  areas  within  each  cell,  may  highlight  the  need  for 
further  research  and  development.  Areas  lacking  standardization,  consensus,  or 
interoperable  migration  pathways  may  also  need  to  be  scrutinized  for  suitabihty  to  long- 
term Nil  technology  deployment  guidelines.  Likewise,  cells  that  incorporate  a large 
variety  of  interface  technologies  should  quite  possibly  be  regarded  as  over-encumbered 
with  interfaces,  which  may  tend  to  propagate  noninteroperable  implementations. 

Further  discussions  of  the  contents  of  the  table  with  industry,  academic  institutions,  and 
other  government  agencies  are  planned  during  the  document  review  workshop.  It  is 
expected  that  these  discussions  will  provide  the  information  needed  to  populate  the  table, 
thereby  permitting  a common  structuring  of  the  key  enabling  services.  Proper  definition  of 
the  services,  in  combination  with  detailed  interface  and  specification  justifications,  will 
then  help  coordinate  future  directions  and  resolve  many  of  the  open  issues  surfacing  within 
the  current  definition  of  the  Services  Framework. 

To  illustrate  how  the  cross-industry  table  may  be  completed,  two  specific  examples  are 
detailed  here.  The  interfaces  and  services  required  for  information  to  flow  between  the 
entertainment  and  telecommunications  industries  are  discussed  in  detail  in  Section  D.2.1. 
Section  D.2.2  details  more  briefly  the  aspects  of  sending  information  from  the  wireless 
domain  through  several  networking  substrates  or  technologies.  Several  perspectives  are 
highlighted  to  illustrate  many  of  the  key  interworking  issues  that  need  to  be  addressed  to 
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achieve  better  bridging  between  the  very  large  telecommunications  industry  and  various 
public  and  private  data  networks — ^an  issue  that  has  not  been  addressed  in  detail  by  the  Nil 
community  as  a whole. 


D.2  EXAMPLES  OF  BITWAY  INTERCONNECTIONS 

It  is  envisioned  that  the  bitways  vdU  be  engineered  in  such  a way  as  to  provide  the 
functionality  needed  to  support  aU  higher-layer  service  sets  envisaged  within  the  Nil 
Services  Framework.  This  expansion  should  bring  forth  and  highlight  the  key  interfaces 
within  the  NH. 

To  provide  the  much-needed  vertical  connectivity  among  the  various  service  entities 
throughout  the  framework,  various  emerging  Nil  services  need  to  be  examined.  One 
method  of  doing  this  involves  examining  several  industry  intersections  within  the  cross- 
industry profile  table.  To  begin  populating  the  table,  two  examples  that  use  multiple 
bitway  interconnects  were  selected.  The  first  example  is  based  on  existing  technology  and 
practice,  while  the  second  represents  a hypothetical  view  of  how  such  an  interconnection 
may  be  implemented.  In  practice,  other  options  may  be  used. 


D.2.1  Interfaces  Between  the  Entertainment  and  Telecommunications  Industries 

In  this  first  example,  to  illustrate  the  interfaces  between  the  entertainment  and 
telecommunications  industries,  the  emerging  video  on  demand  (VOD)  service  is  examined. 
The  VOD  industry  currently  requires  the  use  of  advanced  digital  backbones  and  local 
exchange  offices  provided  by  the  long-distance  carriers  and  Regional  BeU  Operating 
Companies  (RBOCs),  respectively.  The  entertainment  industry,  through  its  use  of  the 
cable  television  (CATV)  systems,  wiU  have  to  interface  with  these  telecommunications 
carriers.  How  vdll  this  be  accomphshed?  What  are  the  required  interfaces,  services, 
protocols,  and  standards?  To  answer  these  questions  it  wiU  be  necessary  to  resolve  legal 
and  regulatory  issues  necessary  to  enable  interoperation  between  the  entertainment  and 
telecommunications  industries. 

In  general,  the  high-level  services  needed  to  provide  the  entertainment-to- 
telecommunications  hnks  consist  of  broadband  communications  and  video-content 
oriented  delivery  services.  These  high-level  services,  in  turn,  must  be  developed  using 
underlying  services  and  core  technology.  The  interfaces  providing  this  connectivity  are 
discussed  below. 
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Experimental  trials  of  VOD  are  currently  being  conducted.  A set-top  box  much  like  a 
cable  TV  converter  is  used  to  allow  the  subscriber  to  request  a movie  from  the  service 
provider.  A control  system  is  used  to  signal  the  user’s  request  to  the  service  provider’s 
video  server  system,  where  billing  and  initiahzation  procedures  take  place.  The  movie  is 
then  delivered  to  the  home  of  the  requester  and  possibly  to  other  locations  simultaneously. 
To  reduce  up-front  storage  requirements  and  provide  subsequent  transmission  efficiency 
of  the  movie,  the  information  is  stored  in  a Motion  Pictures  Experts  Group  (MPEG)-2 
compressed  format.  Existing  coaxial  analog  cabling  plant  is  used  in  these  experiments  as 
an  interim  solution. 

In  the  case  of  existing  telephone  copper  cabhng  plants,  advanced  transmission  systems 
based  on  state-of-the-art  modulation  techniques  called  asymmetric  digital  subscriber  loop 
(ADSL)  are  used  to  transmit  movies  over  the  phone  lines  to  the  set-top  device  using  a 
Narrowband  Integrated  Services  Digital  Network  (N-ISDN)  interface.  Within  the  service 
provider’s  transmission  backbone,  the  use  of  asynchronous  transfer  mode  (ATM) 
technology  has  been  the  primary  vehicle  for  distributing  movies  to  subscribers.  At  some 
point,  the  underlying  ATM-based  transmission  must  be  converted.  Where  this  conversion 
process  takes  place  is  typically  up  to  the  service  provider,  allowing  ATM  termination  at 
the  video  server  or  extended  all  the  way  to  the  curb  if  the  fiber  exists  at  that  point. 

Finally,  different  VOD  architectures  prescribe  variants  on  where  decompression  of  the 
video  stream  takes  place.  Some  providers  prefer  to  send  MPEG-2  streams  to  the  set-top 
device,  while  others  limit  the  distribution  point  and  use  traditional  analog  methods  to 
facilitate  typical  TV  applications. 

The  above  VOD  example  highlights  many  complex  interactions,  and  along  with  the  variety 
of  technologies  used  as  “jump-off’  points,  translates  into  numerous  services  and  a variety 
of  bitway  technologies.  These  various  services  and  interfaces  represent  the  technology 
found  at  the  intersection  point  between  the  entertainment  and  telecommunications 
industries.  The  network  types  and  service  attributes  listed  in  Section  5.1  are  used  as 
partitioning  tools  to  describe  the  interfaces  and  services  required  to  facilitate  the 
interconnection.  These  include  the  following: 

• User  information  appliance 

- Devices: 

- Set-top  devices 
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- Other  independent  devices  (ranging  from  low-end  PC-based  models  to 
high-end  graphics-based  engines,  also  called  subscriber  terminals), 
televisions,  computers,  remote  controls,  and  other  related  peripherals 

- Services: 

- User  interface,  presentation,  and  control 

- Line  transceiver,  demodulation,  decompression 

- Back  channel  interface,  remote  functions 

- Video  display  driver  capabihties 

- Interfaces: 

- RS-232X,  coaxial  cable,  optical  fiber 

- Windows-based  PC,  TV  channels,  remote  control  process 

• Content/Format 

- Services:  transport  and  encoded  content  for  digital  video  streams 

- Interfaces: 

- MPEG  1 

- MPEG  2 

- Encoded  digital  audio/video  streams 

• Distributed  control 

- Services: 

- MPEG  2 system  layer  control  for  transport  stream 

- Video  dial  tone  (VDT)  gateway  control 

- Maintenance  of  stream  mapping  table  in  VDT  gateway 

- Interfaces: 
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- MPEG  II  system  layer  control  interface 

- Federal  Communications  Commission  (FCC)  mandated 

- Level  1/2  VDT  gateway  interfaces 
• Core  networking  services 

- Services: 

- Signaling  between  subscriber  terminals  and  VDT  gateway 

- Stream  management  for  the  video  server 

- Security  and  encryption  services 

- Scrambling 

- Key  encryption 

- Forward  error  correction  (FEC),  synchronization  and  jitter,  procedural 
aspects  of  network  interface,  backbone  signaling 

- Management  of  network,  operations,  and  end-to-end  control 

- Billing  and  accounting  operations 

- Higher-level  protocols,  such  as  User  Datagram  Protocol/Intemet  Protocol 
(UDP/IP)  are  used  in  the  VDT  gateway  for  control 

- Interfaces: 

- Transmission  Control  Protocol/Intemet  Protocol  (TCP/IP) 

- Upstream/downstream  TV  channels  using  offset  quadrature  phase  shift 
keying  (QPSK)  modulation 

- Serialized  firmware,  encryption  device  interface,  conditional  access  systems 

- Conforming  interface  standards  for  telecommunications  management 
networks  (TMN) 
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Mostly  proprietary  interfaces  for  most  billing  and  accounting  systems  in  the 
service  operations  centers 


• Bitway 


- Services: 

- Transport  of  information  via  electrical,  optical,  and  carrier  wave  devices 
~ Transport  streams  for  MPEG  2 stream  layer 

- Physical-level  framing 

- Flow  control 

- Multiplexing 

- Adaptation  of  information  stream 

- Signaling  and  control 

- Interfaces  for  backbone,  community  network,  and  switching  office: 

- Fiber  optic  cable,  wireless,  video  dial  tone  (VDT)  network 

- CATV  with  analog  modulation,  CATV  with  digital  modulation 

- Unshielded  twisted  pair  (UTP),  passive  optical  networks 

- Hybrid  fiber  and  coax,  hybrid  fiber  and  twisted  pair 

- Hybrid  fiber  and  wireless 

- Asymmetric  digital  subscriber  hne  (ADSL) 

- SONET,  ATM,  Signahng  System  7 (SS7),  and  Narrowband/Broadband 
(N/B)  ISDN.  (The  video  stream  is  transported  over  a standard 
6 megahertz  TV  channel  using  64  quadrature  amplitude  modulation 
[QAM].) 

- OC-3  interface  (155  Mb/s) 

- AM-VSB  Signals  in  the  50  - 450  MHz  signal  band 


D-6 


D.2.2  Interfaces  Between  the  Wireless  and  Various  Telecommunications  Industries 


In  the  process  of  interconnecting  different  networks,  a number  of  issues  must  be 
examined.  The  architecture  of  the  network,  services  provided  by  the  network,  and  the 
signaling  used  to  control  the  network  are  important  and  highly  interrelated.  Current 
architectures  consist  of  either  a hierarchical  or  nonhierarchical  numbering  plan  and 
synchronous  (with  timing)  or  asynchronous  (without  timing)  transmission  modes. 
Numerous  services  must  be  considered,  and  each  needs  to  be  examined  individually  when 
using  different  networks.  Voice  and  raw  data  services  are  used  here  as  examples  to 
illustrate  these  relationships.  The  signahng  is  used  to  set  up  a communications  path  from 
point  A to  point  B;  then  data  is  transferred  along  such  a path. 

In  this  second  example,  four  different  networks — a wireless,  a digital  telephone/ISDN,  an 
ATM  network,  and  the  Internet — are  used  to  illustrate  the  two  example  services. 


Wireless  Telephone/ISDN  ATM  Internet 


Figure  D-1.  Voice  Service. 


First  the  voice  service  is  examined  as  it  traverses  different  networking  substrates  and 
protocol  stacks.  The  voice  service  is  a continuous  stream  of  analog  data.  In  a digital 
telephone/ISDN  network,  the  voice  processing  uses  a sampling  rate  algorithm  and  a 
coding  method  for  those  samples  in  order  to  transform  the  continuous  analog  signal  into  a 
continuous  digital  bit  stream.  In  today’s  networks,  two  encoding  algorithms  are  used  that 
interwork  transparently:  p.-law  for  the  United  States  and  A-law  for  others.  In  a wireless 
network  where  data  rates  are  low,  a different  sampling  rate  and  coding  algorithm  are  used 
that  generate  low  data  rates  and  perhaps  even  partition  the  digitized  voice  signals  into 
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packets.  Therefore,  if  a voice  signal  on  a wireless  network  needs  to  reach  a party  on  a 
telephone/ISDN  network,  an  interworking  function  must  exist  to  convert  the  samphng 
rate,  as  well  as  the  coding  of  those  samples.  For  an  ATM  network,  voice  data  streams 
may  be  rate-adapted.  To  maintain  timing  within  the  voice  stream,  a specific  ATM 
Adaptation  Layer  (AAL  type  1)  is  used.  In  contrast,  within  the  Internet,  voice  data  is 
packetized,  and  therefore  needs  to  be  rate-adapted  as  well  as  decoded  during  interworking 
with  other  networks.  In  addition,  it  should  be  noted  that  encryption,  particularly  end-to- 
end  encryption,  adds  further  technical  complexity  to  interface  standards.  See  Figure  D-1. 


Wireless  Telephone/ISDN  ATM  Internet 


Figure  D-2.  Raw  Data  Service. 


For  a raw  data  service,  the  interworking  functions  are  different  from  those  for  the  voice 
service.  In  a digital  telephone/ISDN  network,  raw  data  can  be  as  simple  as  a digital  bit 
stream  from  the  computer  into  the  network.  In  a wireless  network,  this  digital  bit  stream 
would  need  to  be  rate-adapted  for  interworking  with  a faster  network.  In  an  ATM 
environment,  a raw  data  stream  may  use  the  ATM  cell  payload  directly,  or  it  may  use  an 
AAL  (AAL  type  5)  which  was  designed  for  data  applications.  The  choice  of  which  stack 
an  ATM  network  uses  will  depend  on  whether  there  are  any  additional  features  required 
(e.g.,  error  correction).  Additionally,  there  may  need  to  be  rate  adaptation  between  ATM 
networks  and  other  networks.  In  the  Internet,  aU  data  is  sent  in  packets,  and  therefore 
must  be  reformatted  for  interworking  with  other  networks.  See  Figure  D-2. 
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Signaling  plays  a critical  role  in  interworking  of  diverse  networks  and  may  perhaps  be  the 
most  important  item  to  ease  interworking  problems.  In  finding  a path  from  point  A to 
point  B across  diverse  networks,  signaling  may  undergo  address  conversion  (e.g., 
telephone  numbering  plan  to/from  IP  addresses),  message  conversion  (e.g.,  ISDN  connect 
to/from  Open  Systems  Interconnection  [OSI]  connect),  or  routing  conversion. 

In  ISDN,  the  signaling  messages  contain  other  valuable  information  to  aid  in  the  selection 
of  interworking  functions.  For  example,  the  bearer  capabihty  information  element 
identifies  a type  of  service  being  requested  of  the  network.  This  information  can  be  used 
by  the  network  to  select  different  paths  or  interworking  functions.  For  example,  if  the 
bearer  capability  were  coded  as  speech  and  p-law,  the  ISDN  would  know  that  it  could 
route,  convert,  and  pass  this  call  on  to  an  attached  telephone  network  because  both 
networks  support  voice  networks.  However,  if  the  bearer  capability  were  coded  as  digital 
data,  the  ISDN  would  not  be  able  to  route,  convert,  or  pass  that  call  to  the  telephone 
network.  In  this  case,  the  caU  would  be  rejected  because  a network  in  the  path  could  not 
support  the  service. 

Wireless  Telephone/ISDN  ATM  Internet 


B-ISDN 


ATM  Forum 


Figure  D-3.  Signaling  Service. 


A wireless  network  has  a similar  signaling  method  that  is  tailored  to  its  architecture,  as 
does  the  ATM  network.  The  Internet,  on  the  other  hand,  does  not  have  this  capability. 
Therefore,  the  networks  to  which  the  Internet  connects  must  assume  that  it  supports  only 
a certain  type  of  connection.  Sometimes,  the  same  technology  (e.g.,  ATM)  is  used  in 
different  ways  which  require  interworking  functions.  ATM  as  defined  by  the  telephone 
companies  is  used  differently  than  ATM  as  defined  by  the  Internet  community.  The 
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telephone  companies  use  a different  protocol  stack  and  addressing  scheme  above  ATM 
than  that  used  by  the  Internet  community.  See  Figure  D-3. 

The  services  and  interfaces  defined  by  the  above  examples  fall  within  the  general 
categories  cited  below.  These  categories  implicitly  describe  the  issues  that  affect  this 
particular  aspect  of  cross-industry  participation;  therefore,  it  is  beneficial  to  the  services 
definition  process  to  partition  interworking  accordingly.  Cross-industry  intersections  are 
constrained  by  the  following: 

• Information  appliance  data  rates 

• Modulation  techniques 

• Direction  of  communications 

• Hybrid  bitway  interconnects 

• Analog  and  digital  distribution 

• Broadband  services  availabihty 

• Technology  options  for  delivery 

• Signaling  issues 


D.2.3  Technical  Bitway  Issues  Derived  from  the  Examples 

The  available  technology  options  with  respect  to  broadband  communications  and  video 
delivery  services  also  serve  to  summarize  and  define  many  of  the  specific  areas  required 
for  further  study.  Section  5 highlights  many  of  the  higher-level  generic  issues  within  the 
bitway  interworking  problem  space. 

Looking  at  each  service  type  area  with  respect  to  the  intersection  of  industries  also 
highhghts  very  specific  technical  issues  that  form  the  basis  of  the  recommendations  in 
Section  5.  These  are  key  aspects  of  the  technology  environment  that  specifically  address 
the  high-level  issues  just  outlined.  Some  of  the  more  important  issues  uncovered  while 
studying  these  specific  types  include  the  following: 
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• Harmonization  is  needed  within  the  wireless  community  regarding  finalization  of 
the  Common  Air  Interface  Proposals.  (This  is  a relatively  fast-moving  area,  with 
many  issues  still  pending.) 

• Coordinated  efforts  to  use  the  Common  Channel  Signaling  protocol  (SS7)  within  a 
common  framework  are  required  for  interoperable  interexchange  carriers  (lECs) 
and  local  exchange  carriers  (LECs),  and  guaranteed  service  availability.  (This  is  an 
issue  shown  to  exist  even  among  similar  SS7  implementations.) 

• The  asymmetric  nature  of  the  emerging  ADSL  interface  technology  will  need  to  be 
addressed  further  for  supporting  higher-rate  upstream  traffic.  (This  issue  will  be 
determined  by  researching  the  ADSL  scheme  used  to  dehver  digital  information  to 
an  analog  delivery  medium  such  as  the  TV.) 

• Noise  levels  associated  with  existing  copper  plant  in  the  home  will  require  further 
R&D  prior  to  widespread  installations  of  ADSL  in  the  loop.  (This  issue  will  be 
determined  by  researching  the  ADSL  scheme  used  to  deliver  digital  information  to 
an  analog  delivery  medium  such  as  the  TV.) 

• Fiber-to-the-Curb  (FTTC)  issues  (or  lack  thereof)  determine  significantly  what 
engineering  constraints  and  capabilities  must  be  factored  into  the  network 
interfaces  to  support  various  bitway  traffic  patterns,  and  content.  (This  issue  is 
shown  currently  by  analog  and  digital  solutions  within  the  networks.) 

• Open,  common  interfaces  for  maintaining  security  and  integrity  of  data  within  the 
various  industry  sectors  is  a major  concern  and  needs  to  be  addressed  in  detail. 
(This  issue  is  shown  by  the  lack  of  interfaces.) 

• Ubiquitous  use  of  Synchronous  Optical  Network  (SONET)/Synchronous  Data 
Hierarchy  (SDH)  and  ATM  for  basic  transmission  purposes  is  evident.  (Common 
carriers  are  already  putting  these  backbones  in  place,  with  the  Optical  Carrier 
(OC)-3  physical  interface  becoming  the  most  widely  accepted.) 

• Operations,  administration,  and  management  (OAM),  maintenance,  directory 
services,  and  billing  interfaces  are  currently  highly  proprietary.  (This  issue  is 
shown  by  the  lack  of  openly  available  interfaces.) 

• Convergence  of  digital  video  streams  to  a few  ubiquitous  formats,  such  as  MPEG 
and  motion  Joint  Photographies  Expert  Group  (JPEG),  is  necessary.  Other 
encoding  schemes  for  better  quality  levels  can  then  be  used  if  MPEG  is  used  as  the 
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underlying  encoding  for  the  digital  transmission.  (This  issue  is  shown  by  a large 
cross-section  of  MPEG  interface  usage.) 

• The  FCC  ruling  in  1991  allowing  the  VDT  network  services  enables  an  “open  level 
one  gateway”  and  associated  architecture  to  be  put  in  place.  Future  coordination 
with  FCC  regulators  may  increase  the  long-term  competitiveness  of  these 
industries. 

• Analog  and  digital  loops  for  transmission  introduce  many  engineering  problems, 
including  increased  overhead,  higher  equipment  costs,  and  increased  dehvery 
processing,  in  contrast  with  digital  dehvery  end-to-end  using  fiber-based 
technology. 

• Use  of  MPEG  compression  with  ATM  is  imminent;  further  R&D  into  this 
transport  format  is  required. 

• Harmonizing  N/B  ISDN  interfaces  with  ATM  transmission  technologies  will 
essentially  provide  ubiquitous  access  to  integrated  interface  services. 

• Bearer  services  will  need  to  be  defined  in  terms  of  abstract  services  such  as  quahty 
of  service  (QOS)  for  bandwidth,  delay,  and  loss. 
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E.  OPEN  SYSTEM  ENVIRONMENT 


From  the  perspective  of  users  and  technologists  alike,  an  open  system  environment  (OSE) 
consists  of  a computing  support  infrastructure  which  facilitates  the  acquisition  of 
applications  that: 

• Execute  on  any  vendor’s  platform. 

• Use  any  vendor’s  operating  system. 

• Access  any  vendor’s  database. 

• Communicate  and  interoperate  over  any  vendor’s  networks. 

• Are  secure  and  manageable. 

• Interact  with  users  through  a common  human-computer  interface. 

In  more  technical  terms,  an  OSE  is  a computing  environment  that  supports  portable, 
scalable,  and  interoperable  applications  through  standard  services,  interfaces,  data  formats, 
and  protocols.  The  standards  may  consist  of  international,  national,  industry,  or  other 
open  (public)  specifications.  These  specifications  are  available  to  any  user  or  vendor  for 
use  in  building  systems  and  products  that  meet  OSE  criteria. 

Applications  in  an  OSE  are  scalable  among  a variety  of  platform  and  network 
configurations,  from  stand-alone  microcomputers  to  large  distributed  systems  that  may 
include  microcomputers,  workstations,  minicomputers,  mainframes,  and  supercomputers, 
or  any  configuration  between.  The  existence  of  greater  or  fewer  computing  resources  on 
any  platform  will  be  apparent  to  users  only  in  the  context  that  they  affect  the  application’s 
speed  of  execution,  for  example,  in  how  fast  screens  are  refreshed  or  data  is  retrieved,  or 
the  capacity  of  each  platform  to  process  data  (e.g.,  16-bit  data  bus  versus  a 32-  bit  bus). 

Applications  interoperate  by  using  standard  communications  protocols,  data  interchange 
formats,  and  distributed  system  interfaces  to  transmit,  receive,  understand,  and  use 
information.  The  process  of  moving  information  from  one  platform  through  a local  area 
network,  wide  area  network,  or  combination  of  networks  to  other  platforms  should  be 
transparent  to  the  application  and  the  user.  Locations  of  other  platforms,  users,  databases, 
and  programs  should  also  be  transparent  to  the  application. 
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In  short,  an  OSE  supports  applications  through  the  use  of  weU-defmed  components:  a 
plug-compatible  technology  or  building-block  approach  for  developing  systems. 

Unfortunately,  not  enough  standards  are  in  place  to  define  an  OSE  completely.  Standards 
organizations  are  working  on  this  problem,  but  much  effort  is  still  needed.  As  technology 
changes,  some  standards  will  become  obsolete,  and  other  new  ones  wiU  be  required. 
Organizations  can  still  accomplish  a great  deal  in  moving  toward  an  OSE  by  selecting 
specifications  that  will  provide  greater  openness  over  time. 


E.l  OSE  REFERENCE  MODEL 

The  Institute  of  Electrical  and  Electronics  Engineers  (IEEE)  POSIX  Working  Group 
PI 003.0  describes  an  OSE  Reference  Model  (OSE/RM)  that  is  closely  ahgned  with  the 
Application  Portability  Profile  (APP)  and  that  provides  a framework  for  describing  open 
system  concepts  and  defining  a lexicon  of  terms  that  can  be  agreed  upon  generally  by  all 
interested  parties.  Figure  E-1  illustrates  the  OSE/RM. 


Figure  E-1.  Open  System  Environment  Reference  Model  (OSE/RM) 
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Two  types  of  elements  are  used  in  the  model:  entities,  consisting  of  the  application 
software,  application  platform,  and  platform  external  environment;  and  interfaces, 
including  the  application  programming  interface  (API)  and  external  environment  interface. 

The  three  classes  of  OSE/RM  entities  are  described  as  follows: 

• Application  Software.  Within  the  context  of  the  OSE/RM,  the  application 
software  includes  data,  documentation,  and  training,  as  well  as  programs. 

• Application  Platform.  The  application  platform  is  composed  of  the  collection  of 
hardware  and  software  components  that  provide  the  system  services  used  by 
application  software. 

• Platform  External  Environment.  The  platform  external  environment  consists  of 
those  system  elements  that  are  external  to  the  application  software  and  the 
application  platform  (e.g.,  services  provided  by  other  platforms  or  peripheral 
devices). 

There  are  two  classes  of  interfaces  in  the  OSE/RM,  as  described  below: 

• Application  Programming  Interface  (API).  The  API  is  the  interface  between 
the  application  software  and  the  application  platform.  Its  primary  function  is  to 
support  portability  of  application  software.  An  API  is  categorized  according  to 
the  types  of  service  accessible  via  that  API.  There  are  four  types  of  API  services 
in  the  OSE/RM: 

- Human-computer  interface  services 

- Information  interchange  services 

- Communications  services 

- Internal  system  services 

• External  Environment  Interface  (EEI).  The  EEI  is  the  interface  that  supports 
information  transfer  between  the  application  platform  and  the  external 
environment,  and  between  applications  executing  on  the  same  platform. 
Consisting  chiefly  of  protocols  and  supporting  data  formats,  the  EEI  supports 
interoperability  to  a large  extent.  An  EEI  is  categorized  according  to  the  types  of 
information  transfer  services  provided.  There  are  three  types  of  information 
transfer  services,  to  and  from  the  following: 

- Human  users 
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External  data  stores 


- Other  application  platforms 

In  its  simplest  form,  the  OSE/RM  illustrates  a straightforward  user-supplier  relationship: 
the  application  software  is  the  user  of  services,  and  the  application  platform/extemal 
environment  entities  are  the  suppliers.  The  API  and  EEI  define  the  services  that  are 
provided. 


E.2  OSE  PROFILE  AND  THE  APP 

A profile  consists  of  a selected  List  of  standards  and  other  specifications  that  define  a 
complement  of  services  made  available  to  applications  in  a specific  domain.  Examples  of 
domains  might  include  a workstation  environment,  an  embedded  process  control 
environment,  a distributed  environment,  a transaction  processing  environment,  or  an  office 
automation  environment,  to  name  a few.  Each  of  these  environments  has  a different 
cross-section  of  service  requirements  that  can  be  specified  independently  from  the  others. 
Each  service,  however,  is  defined  in  a standard  form  across  all  environments. 

An  OSE  profile  is  composed  of  a selected  list  of  open  (public),  consensus-based  standards 
and  specifications  that  define  services  in  the  OSE/RM.  Restricting  a profile  to  a specific 
domain  or  group  of  domains  that  are  of  interest  to  an  individual  organization  results  in  the 
definition  of  an  organizational  profile.  The  APP  is  an  OSE  profile  designed  for  use  by  the 
U.S.  Government.  It  covers  a broad  range  of  application  software  domains  of  interest  to 
many  federal  agencies,  but  it  does  not  include  every  domain  within  the  U.S.  Government’s 
application  inventory.  The  individual  standards  and  specifications  in  the  APP  define  data 
formats,  interfaces,  protocols,  or  a mix  of  these  elements. 
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